[swift-evolution] Custom didSet methods

[Austin Zheng]

https://gist.github.com/jckarter/f3d392cf183c6b2b2ac3 <https://gist.github.com/jckarter/f3d392cf183c6b2b2ac3>

> On Jan 13, 2016, at 12: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/20160113/42df7c4d/attachment.html>