[swift-evolution] Custom didSet methods

[Wallacy]

This proposal of Property Behaviors is amazing! Thanks a lot Joe Groff
<https://github.com/jckarter> (and others).


Em qua, 13 de jan de 2016 às 06:50, Austin Zheng via swift-evolution <
swift-evolution at swift.org> escreveu:

> 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
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> 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/20160113/3ec7118e/attachment.html>