[swift-evolution] Custom didSet methods

[Ricardo Parada]

Hi Charles,

I believe you can find the latest version (as of yesterday) here:

https://gist.github.com/jckarter/50b838e7f036fe85eaa3 <https://gist.github.com/jckarter/50b838e7f036fe85eaa3>
See also this email from Joe Groff summarizing the changes:

> On Jan 13, 2016, at 5:07 PM, Joe Groff via swift-evolution <swift-evolution at swift.org <mailto: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 <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


> On Jan 13, 2016, at 3:49 AM, Charles Srstka via swift-evolution <swift-evolution at swift.org> wrote:
> 
> On 2016-01-12 23:45, Chris Lattner wrote:
>> On Jan 12, 2016, at 8:07 PM, Dave via swift-evolution
>> <swift-evolution at swift.org> wrote:
>>>> What KVO did was to offer an NSKeyValueSetMutationKind enum containing constants for insertion and removal as well as OR and AND operations with other sets. If you don't want to do that, another possible interface could be to provide two ranges, one representing the range of the affected region before the change, and another representing it afterward. If you had an empty range for "before" and a non-empty range for "after", that would represent an insertion. The reverse would be removal, and anything else would be a replacement of some kind.
>>>> Charles
>>> Also, good points. I guess my idea then is:
>>> “did/willUpdate”, “did/willInsert”, and “did/willRemove” for when you don’t care about which element was changed (and for types that aren’t indexable anyway)
>>> “did/willUpdateAtIndex”, “did/WillInsertAtIndex”, and “did/WillRemoveAtIndex” for single elements
>>> “did/willUpdateInRange”, “did/WillInsertInRange”, and “did/WillRemoveInRange” for multiple elements
>>> That’s a lot of new keywords, though… Oh! What if it was *only* did/willUpdate, did/willAdd, and did/willRemove, and they were overloaded with (), (atIndex: Index), and (inRange: Range<Index>) forms? Like this:
>> Just a random comment on this thread:  our desire is to introduce
>> property behaviors, and “demote” things like property observers into
>> library features.  This is great because it makes it much easier to
>> extend these capabilities without hacking on the compiler, and will
>> allow you to define custom behaviors in your own code.
>> I don’t know if the first round of behaviors will actually allow us to
>> eliminate willset/didset though, simply given that they need to poke
>> at the super implementation.  That said, we’d rather work towards
>> fixing those problems: proposals to make the existing property
>> observers richer aren’t likely to be accepted.
>> -Chris
> 
> Is the proposal document for the property behaviors concept available online anywhere? I'm intrigued by it, and would like to read about the specifics.
> 
> Thanks,
> Charles
> 
> _______________________________________________
> 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/20160115/bd64b741/attachment.html>