[swift-evolution] Getting rid of willSet/didSet
Colin Cornaby
colin.cornaby at mac.com
Tue Dec 15 10:26:04 CST 2015
I think the below proposal also tries to pave over the difference between will and didSet, which are both important. In addition to unclear use of super.foo.
> On Dec 15, 2015, at 12:57 AM, Adrian Kashivskyy via swift-evolution <swift-evolution at swift.org> wrote:
>
> I'm -1 on that, willSet and didSet are great tools for performing side effects (such as locking, for example). It was a major problem in Objective-C, as no easy solution (except overriding accessors) existed and still you'd have to write a lot of boilerplate code.
>
> Pozdrawiam – Regards,
> Adrian Kashivskyy
>
>> Wiadomość napisana przez Nicky Gerritsen via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> w dniu 15.12.2015, o godz. 08:50:
>>
>> But how does this work if `super` does not have `foo`, exactly like in this example? UIView does not have a member named `foo`, so it will not work.
>> Moreover, currently if creating a setter, you also need to supply a getter.
>>
>> Regards,
>>
>> Nicky
>>
>> On 12/15/2015 08:23 AM, Tino Heth via swift-evolution wrote:
>>>> It *is* odd, and I do the described didSet trick *all* the time.
>>>>
>>>> Stuff like:
>>> The alternative wouldn’t be that complicated:
>>>
>>> public class MyView: UIView {
>>> public var foo: Int {
>>> set(value) {
>>> super.foo = value
>>> setNeedsDisplay()
>>> }
>>> }
>>> }
>>>
>>> It’s just one line more, but three(!) keywords less that could be removed from the language; and I bet in the wild there are many thousand errors in subclasses of UIViewController that happen because the author didn’t remember wether he has to call super in viewDid…, loadView etc.
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto: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/20151215/f843351c/attachment.html>
More information about the swift-evolution
mailing list