<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. 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. 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. 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. </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. 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. 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. 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. </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. So for example, if you accessed <font face="Monaco" class="">aBlog.author</font> it would return an <font face="Monaco" class="">EOFault</font> as a stand-in for the <font face="Monaco" class="">Person</font> object. </div><div style="font-size: 15px;" class=""><br class=""></div><div style="font-size: 15px;" class="">If you then messaged the fault object with <span style="font-family: Monaco;" class="">name</span>, then the fault is given a chance by the Objective-C runtime to forward the <span style="font-family: Monaco;" class="">name</span> 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 <span style="font-family: Monaco;" class="">name</span> message. 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. Then NeXT ported Enterprise Objects Framework to java relying on <font face="Monaco" class="">willRead()</font> 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. <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. 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 <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> 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>