[swift-evolution] [Review] SE-0030 Property Behaviors

[Myles La Verne Schultz]

On Feb 19, 2016, at 12:01 AM, Curt Clifton via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:

> 
>> On Feb 18, 2016, at 6:56 PM, Joe Groff via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> Based on review feedback, I've revised the declaration syntax proposal for property behaviors to be more in line with our other declaration forms, reverting to the earlier pre-review "var behavior" proposal. I've updated the proposal in swift-evolution:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0030-property-behavior-decls.md <https://github.com/apple/swift-evolution/blob/master/proposals/0030-property-behavior-decls.md>
> The updated behavior declaration form is largely an improvement. 
> 
> With the placeholder for binding the name of the attributed property gone from the grammar, I wonder if you’ve given any thought to how that binding might be done. I recognize that the binding is left for future work, but would hate to see my pet feature painted into a corner.
> 
> I find the naked `initialValue` “declaration" quite odd. It’s not exactly a declaration even.

I find the 'initialValue' declaration a little odd as well. Also, when looking at the proposal, most of the behaviors have one of these declared. For a given property with multiple behaviors, we are holding onto duplicate data. Perhaps I'm just misunderstanding the proposal?

> What are the implications for parsing? If we’re already willing to special case`initialValue` in the parser in this context, perhaps we could introduce a binding list instead, like:
> 
> ```
> public var behavior lazy<Value>: Value {
>   // Behaviors can bind the property's initializer expression with a
>   // binding declaration.
>   bind initialValue
>   …
> ```

Is this binding like a reference to the actual property? I think it would be awesome if there were a way for the behavior's 'value' property to bind or reference the property to which the behavior is being applied. Then, there isn't any duplicate data, and the behavior is actually acting on the property. Personally, a given behavior acting on the property I have assigned it to is what I am expecting to happen. Not a behavior that works on some mysterious value that then sets the property. 

To achieve this, could we have behaviors decide how a property is fundamentally treated instead of add functionality? Meaning a behavior such as lazy accesses the actual property value when doing its operations. At initialization of the property, lazy allows for reservation of space for the properties type, but doesn't not assign a value to it until the property gets called on. 

In a sense we'd be making a property/computed property hybrid where the computer part is defined by the user's defined behavior. 

> Besides eliminating the odd naked “declaration”, this has the added advantage that it could be extended to `bind initialValue, propertyName`. :-)
> 
> Also, the initialValue in the “Proposed Solution” section doesn’t match the naked syntax used throughout the Examples section.
> 
>> In discussion with the core team, we've also strongly come in favor of applying behaviors to properties using attribute syntax, e.g.:
>> 
>> @lazy var x = 111
>> @delayed var x: Int
>> 
>> They're definitely attribute-like, and we think it makes sense for behaviors to be the first of hopefully many kinds of user-defined behaviors. What do you all think of this direction?
> 
> I think this is an excellent direction. Would we also use @ syntax for accessing property-supplied members, like `a at runcible.x <mailto:a at runcible.x>`?
> 
> Cheers,
> 
> Curt
> -----------------------------------------------------------------------------
> Curt Clifton, PhD
> Software Engineer
> The Omni Group
> www.curtclifton.net <http://www.curtclifton.net/>
> 
> 
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160219/f87a89cb/attachment.html>