[swift-evolution] Custom didSet methods

[James Campbell]

I understand and I am aware of this proposal. I only raised this since
collections are a primitive object type that are used quite frequently in
swift. I think it would be acceptable to introduce a generic way of knowing
when an item was added, updated or removed which could be demoted with set
and get.

I think the pros outweigh the cons. Previous proposals such as default
initialisers are either too complex / niche or can already be done via the
swift language. So are better implemented with property behaviours.


*___________________________________*

*James⎥Lead Engineer*

*james at supmenow.com <james at supmenow.com>⎥supmenow.com <http://supmenow.com>*

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On Wed, Jan 13, 2016 at 4:45 AM, Chris Lattner via swift-evolution <
swift-evolution at swift.org> 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
>
> _______________________________________________
> 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/087adc1e/attachment.html>