[swift-evolution] Getting rid of willSet/didSet

[Colin Cornaby]

didSet/willSet is super handy for doing things like updating UI when a property has been set without going through the overhead of writing a full setter or getter. It's useful for many things beyond a super class responding to changes going through a subclass.

Blocking/validating changes seems like something totally different to me. didSet/willSet doesn't really seem meant for change validation necessarily, and I think it's mixing use cases. That almost seems like something where you'd want to move beyond properties (Obj-C certainly doesn't handle validation in this way.)

On Dec 14, 2015, at 02:57 PM, Tino Heth via swift-evolution <swift-evolution at swift.org> wrote:

Hi there!

Considering that I just read that someone wants to have „willGet“, I guess willSet and didSet are here to stay — but for me, the concept has several downsides:
- two special keywords
- oldValue as another special word (there are some of those, but afaics only self and super are used often)
- imho it is not intuitive in which order those methods are called when subclassing
… and all those special rules only work for properties.

I think NS_REQUIRES_SUPER (beside the hard name) is much better, because
- it works for every method (I guess everyone knows some classes in Cocoa where the docs say you must call super, but the compiler cannot enforce this)
- order of execution is clear
- it is easy to block a change, instead of doing a rollback in „didSet“

The only advantage of willSet/didSet is that it is easy to create a stored property and be notified when it is changed, without the need to create an additional field — but I think it wouldn’t be that bad to just write „super.property = value“, even if there is no superclass as backing store: It may appear odd, but shouldn’t cause any problems.

Best regards,
Tino
_______________________________________________
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/20151214/14f0d227/attachment.html>