<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><blockquote type="cite" class="">On Dec 27, 2015, at 4:23 AM, Tino Heth <<a href="mailto:2th@gmx.de" class="">2th@gmx.de</a>> wrote:<br class=""></blockquote><div><blockquote type="cite" class=""><br class="Apple-interchange-newline"><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class=""><span class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;"><br class="Apple-interchange-newline">Of course, if you’re worried about the performance costs associated with that extra method call, you might want to include a keyword, such as “observable”, and only generate the method call(s) if that keyword is on the property.</span></div></blockquote></div><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">I strongly agree that Swift should have/keep a possibility to create properties with no performance penalty — but I guess comfort is more important, so I'd rather make observable the default and offer a possibility to disable it.</span><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">Tino</div></div></blockquote></div><br class=""><div class="">The problem, as I see it, is that KVO is not useful unless the author has specifically thought about it, and if “observable” is not the default, but something that the author of the class had to add, this demonstrates that the author *has* considered KVO compliance for the property. Without some way to know that the property has deliberately been made KVO compliant, code that observes the property cannot be reliable. Therefore, I’d suggest *not* making observable the default, as it ultimately makes KVO a lot more useful.</div><div class=""><br class=""></div><div class="">Example:</div><div class=""><br class=""></div><div class="">class MyObject {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>var foo: Int { get } // This is a computed property, possibly dependent on something else. Can I safely observe it and expect it to work?</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>var bar: Int // This is a stored property—but do I know it won’t be changed to a computed property in the future? Can I observe this and trust my code won’t break in version 2.0?</div><div class="">}</div><div class=""><br class=""></div><div class="">vs.</div><div class=""><br class=""></div><div class="">class MyObject {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>observable var foo: Int { get } // YES I can safely observe this.</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>observable var bar // YES I can safely observe this.</div><div class="">}</div><div class=""><br class=""></div><div class="">Observing things that aren’t observable is fraught with peril (in the current Objective-C implementation, it can often lead to crashes via exceptions being thrown). Knowing that it’s safe is valuable—I’d even say essential. Currently you have to look in the documentation, which as we all know isn’t always complete or up to date. Having the keyword there shows, right in the interface, that the author has committed to making this property compliant and keeping it that way in future releases.</div><div class=""><br class=""></div><div class="">The observable keyword could also allow one to set the KVO key string to something other than just the name of the property:</div><div class=""><br class=""></div><div class="">class MyObject {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>observable(somethingElse) var something: Int</div><div class="">}</div><div class=""><br class=""></div><div class="">You’d also need an annotation to tell the system which other key paths the property is dependent upon, which I’d probably do something like this:</div><div class=""><br class=""></div><div class="">class MyObject {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>observable var foo: Int</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>observable var bar: Int {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>get { return self.foo }</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>set(bar) { self.foo = bar }</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>depends { return [“foo”] }</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}</div><div class="">}</div><div class=""><br class=""></div><div class="">The compiler could automatically add a CollectionType property to the class corresponding to each property, and then rewrite the property setter something like this (pseudocode):</div><div class=""><br class=""></div><div class="">class MyObject {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>private var observersOfFoo: [ObserverProtocol]?</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>observable var foo: Int {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>set(newValue) {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>let oldValue = _foo</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>_foo = newValue // or whatever the default setter usually does</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>self.observersOfFoo?.forEach { $0.notifyKeyValueChanged(self, key: “foo”, oldValue: oldValue) }</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}</div><div class="">}</div><div class=""><br class=""></div><div class="">I made it optional so that for the common case where there aren’t actually any observers on the property, the only performance costs are the store of the old value and checking an optional. Since optionals are basically enums, which are represented as an 8-bit integer which in this case can have the values 0 or 1, I’d expect checking an optional to have similar performance characteristics to checking a boolean, and thus I’d expect it to perform better than checking whether an array is empty, and doing some quick tests seems to back that up.</div><div class=""><br class=""></div><div class="">Charles</div><div class=""><br class=""></div></body></html>