<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><span style="font-size: 15px;" class="">Hi all,</span><div style="font-size: 15px;" class=""><br class=""></div><div style="font-size: 15px;" class="">This looks like a GREAT feature. &nbsp;I’ve read it a few times and I am still assimilating the concepts involved and the syntax.</div><div style="font-size: 15px;" class=""><br class=""></div><div style="font-size: 15px;" class="">I remember in the NeXT days when we had Enterprise Objects Framework, which is similar to Core Data. &nbsp;Model objects were called Enterprise Objects or EOs for short (equivalent to managed objects in Core Data). These objects had properties that represented a to-one relationship or perhaps a to-many relationship. &nbsp;For example, a <font face="Monaco" class="">Blog</font> object could have an <font face="Monaco" class="">author</font> property that pointed to a <font face="Monaco" class="">Person</font> object. &nbsp;</div><div style="font-size: 15px;" class=""><br class=""></div><div style="font-size: 15px;" class="">In Enterprise Objects the object graph was loaded on demand. &nbsp;So for example, you can fetch a <font face="Monaco" class="">Blog</font> object from the database that references a <font face="Monaco" class="">Person</font> object via its <font face="Monaco" class="">author</font> property. &nbsp;Accessing <font face="Monaco" size="2" style="font-size: 14px;" class="">aBlog.author</font> does not incur a fetch of the <font face="Monaco" class="">Person</font> object. &nbsp;However, accessing <font face="Monaco" class="">aBlog.author.name</font> does incur a fetch to bring the corresponding <font face="Monaco" class="">Person</font> object into memory in order to get from it the value for the <font face="Monaco" class="">name</font> property. &nbsp;</div><div style="font-size: 15px;" class=""><br class=""></div><div style="font-size: 15px;" class="">This magic relied on stand-in objects, also known as fault objects (i.e. EOFault) and Objective-C’s selector forwarding amongst other things. &nbsp;So for example, if you accessed&nbsp;<font face="Monaco" class="">aBlog.author</font>&nbsp;it would return an <font face="Monaco" class="">EOFault</font>&nbsp;as a stand-in for the <font face="Monaco" class="">Person</font> object.&nbsp;</div><div style="font-size: 15px;" class=""><br class=""></div><div style="font-size: 15px;" class="">If you then messaged the fault object&nbsp;with&nbsp;<span style="font-family: Monaco;" class="">name</span>, then the fault is given a chance by the Objective-C runtime to forward the&nbsp;<span style="font-family: Monaco;" class="">name</span>&nbsp;message, to which the stand-in responds to by fetching the data for the corresponding <font face="Monaco" class="">Person</font> and turn itself magically into a <font face="Monaco" class="">Person</font> object and send itself the&nbsp;<span style="font-family: Monaco;" class="">name</span>&nbsp;message. &nbsp;At a high level that is how the magic happened. It can be described as elegant, magical or perhaps clever.</div><div style="font-size: 15px;" class=""><br class=""></div><div style="font-size: 15px;" class="">I remember there were many that wanted Enterprise Objects on java but it was argued that java did not have what it took. &nbsp;Then NeXT ported Enterprise Objects Framework to java relying on <font face="Monaco" class="">willRead()</font>&nbsp;calls inside property getter methods to check to see if the data was in memory and fetch it if necessary.</div><div style="font-size: 15px;" class=""><br class=""></div><div style="font-size: 15px;" class="">Now, if I am understanding this property behavior proposal correctly, it seems to me that this mechanism of on-demand loading of an object graph could be implemented using property behaviors. &nbsp;<b class="">Am I right in saying that property behaviors could be used for something like this?</b></div><div style="font-size: 15px;" class=""><br class=""></div><div style="font-size: 15px;" class="">It’s been fascinating reading about this topic and all the different property behaviors. &nbsp;I would imagine there would be a bunch of well known property behaviors implemented in the library somewhere and most developer will be using property behaviors rather than authoring them.</div><div style="font-size: 15px;" class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 13, 2016, at 5:07 PM, Joe Groff via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Thanks everyone for the first round of feedback on my behaviors proposal. I've revised it with the following changes:<br class=""><br class="">- Instead of relying on mapping behaviors to function or type member lookup, I've introduced a new purpose-built 'var behavior' declaration, which declares the accessor and initializer requirements and provides the storage and behavior methods of the property. I think this gives a clearer design for authoring behaviors, and allows for a more efficient and flexible implementation model.<br class="">- I've backed off from trying to include 'let' behaviors. As many of you noted, it's better to tackle immutable computed properties more holistically than to try to backdoor them in.<br class="">- I suggest changing the declaration syntax to use a behavior to square brackets—'var [behavior] foo'—which avoids ambiguity with destructuring 'var' bindings, and also works with future candidates for behavior decoration, particularly `subscript`.<br class=""><br class="">Here's the revised proposal:<br class=""><br class=""><a href="https://gist.github.com/jckarter/50b838e7f036fe85eaa3" class="">https://gist.github.com/jckarter/50b838e7f036fe85eaa3</a><br class=""><br class="">For reference, here's the previous iteration:<br class=""><br class="">https://gist.github.com/jckarter/f3d392cf183c6b2b2ac3<br class=""><br class="">Thanks for taking a look!<br class=""><br class="">-Joe<br class="">_______________________________________________<br class="">swift-evolution mailing list<br class="">swift-evolution@swift.org<br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></div></blockquote></div><br class=""></div></body></html>