> On Mar 30, 2017, at 3:16 PM, Sean Alling <[email protected]> wrote: > John, > > Sure, that is the pattern most commonly adopted for these cases but it does > in fact create a considerable amount of boilerplate code. My hope was to > reduce the amount of boilerplate and the burden to create such a common > pattern of functionality. > > I do understand that the implementation would be complex. I am imagining > that these observers would get magically called when someone adds or removes > the collection. The wrinkle I think you’re referring to is the fact that > there are a variety of ways in which a collection can be 'added to' and > 'removed from’. Is that the complexity you are referring to?
Yes. For example, you could pass the collection as an inout argument to a function that does who-knows-what to it. John. > > Sean > > > >> On Mar 30, 2017, at 2:58 PM, John McCall <[email protected] >> <mailto:[email protected]>> wrote: >> >>> On Mar 30, 2017, at 2:37 PM, Sean Alling via swift-evolution >>> <[email protected] <mailto:[email protected]>> wrote: >>> PROPOSAL: >>> >>> I propose the addition of the following new property observers applicable >>> to all Collection types (Dictionary, Set, and Array): >>> >>> – willAdd(newValue) { … } >>> – didAdd(newValue) { … } >>> >>> – willRemove(oldValue) { … } >>> – didRemove(oldValue) { … } >>> >>> where, `newValue` and `oldValue` are immutable. >>> >>> This would allow one to perform additional work or observer logic to values >>> added and removed from collections. This model is consistent with Swift >>> syntax and may perhaps minimize the use of NSNotifications in some >>> situations. >>> >>> Currently, in order to perform this functionality some filtering and >>> comparison logic would have to be performed from within a `willSet { … }` >>> and `didSet { …}` call. This change would not only ease that burden but >>> promote a more visible and explicit expression that can further improve >>> readability and traceability of functionality. >> >> Figuring out that an arbitrary change to a collection is an "add" or a >> "remove" of a specific element is, well, let's just say it's complex. If >> you're imagining that these observers would just get magically called when >> someone called the add or remove method on the property, that's not really >> how these language features work together. >> >> The property behaviors proposal would let you do things like automatically >> computing differences and calling these observers, if you really want to do >> that. But the better solution is almost certainly to (1) make the >> collection property private(set) and (2) just declare addToList and >> removeFromList methods that do whatever you would want to do in the observer. >> >> John. >> >>> >>> >>> EXAMPLE USAGE: >>> >>> var list = [objects]() { >>> willAdd(newValue) { >>> … >>> } >>> didAdd(newValue) { >>> … >>> } >>> } >>> >>> var list = [key : object]() { >>> willRemove(oldValue) { >>> … >>> } >>> didRemove(oldValue) { >>> … >>> } >>> } >>> >>> >>> ----- >>> Sean Alling >>> [email protected] >>> <mailto:[email protected]>_______________________________________________ >>> swift-evolution mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
