[swift-evolution] [Proposal] Property behaviors

[Ricardo Parada]

Hi all,

This looks like a GREAT feature.  I’ve read it a few times and I am still assimilating the concepts involved and the syntax.

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 Blog object could have an author property that pointed to a Person object.  

In Enterprise Objects the object graph was loaded on demand.  So for example, you can fetch a Blog object from the database that references a Person object via its author property.  Accessing aBlog.author does not incur a fetch of the Person object.  However, accessing aBlog.author.name does incur a fetch to bring the corresponding Person object into memory in order to get from it the value for the name property.  

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 aBlog.author it would return an EOFault as a stand-in for the Person object. 

If you then messaged the fault object with name, then the fault is given a chance by the Objective-C runtime to forward the name message, to which the stand-in responds to by fetching the data for the corresponding Person and turn itself magically into a Person object and send itself the name message.  At a high level that is how the magic happened. It can be described as elegant, magical or perhaps clever.

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 willRead() calls inside property getter methods to check to see if the data was in memory and fetch it if necessary.

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.  Am I right in saying that property behaviors could be used for something like this?

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.




> On Jan 13, 2016, at 5:07 PM, Joe Groff via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Thanks everyone for the first round of feedback on my behaviors proposal. I've revised it with the following changes:
> 
> - 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.
> - 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.
> - 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`.
> 
> Here's the revised proposal:
> 
> https://gist.github.com/jckarter/50b838e7f036fe85eaa3
> 
> For reference, here's the previous iteration:
> 
> https://gist.github.com/jckarter/f3d392cf183c6b2b2ac3
> 
> Thanks for taking a look!
> 
> -Joe
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160115/ef77d2a1/attachment.html>