<div dir="ltr"><div>> Being able to refer to getters and setters is a good idea and aligns with being able to refer to initializers and methods.</div><div>> I would also add subscripts to the list if possible.</div><div><br></div><div>Great idea! Let's discuss syntax</div><div><br></div><div>How about </div><div> - example.get.member</div><div> - example.set.member</div><div> - example.init(argument:Int, another:String)</div><div> - example.subscript(index:Int)</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 14, 2015 at 3:49 AM, Marc Knaup via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Wait, where is stated that KVO is a long-term goal for Swift? I might have missed that.<div><br><div>I find that one of Objective-C's most annoying features. It makes it really difficult to reason about code when things can happen unexpectedly left and right. It's the same issue with aspect-oriented programming.</div></div><div><br></div><div>I prefer explicit integration points like closures, delegates and alike.</div><div>Most times I used KVO in the past was to work around bugs or annoyances on iOS, like for example forcing a button stay enabled even when iOS disables it.</div><div><br></div><div>Also it's unlikely that all mutable properties will support observation automatically. That would require the optimizer to keep using dynamic dispatch for all of them which will hurt performance.</div><div><br></div><div><br></div><div>But I'm getting off-topic since your discussion is not about KVO nor about KVC.</div><div><br></div><div>Being able to refer to getters and setters is a good idea and aligns with being able to refer to initializers and methods.</div><div>I would also add subscripts to the list if possible.</div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Mon, Dec 14, 2015 at 1:34 AM, Michael Henson via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr">Swift-like full KVO/KVC as in Objective-C is a stated long-term goal for Swift's evolution. The 90% solution might be more straightforward:<br><br>class Example {<div> var member: String</div><div><br></div><div> func print() {</div><div> print(self.member)</div><div> }</div><div>}<br><br>var example = Example(member: "Hi!")<br><br>var example_print_method = example.print</div><div>example_print_method()</div><div>result:</div><div>Hi!<br><br></div><div>If there were a mechanism for referring to the getter and setter methods on the var member property as the same kind of self-capturing closures, it could make simple cases of data binding easier to implement:<br><br>var serializeFields = [<br> "member": example.member#get,<br>]<br><br>var deserializeFields = [</div><div> "member": example.member#set,</div><div>]<br><br>var broadcastValueTo = [</div><div> "memberValues": [</div><div> example.member#set,</div><div> example2.member#set,</div><div> example3.member#set,</div><div> ]</div><div>]</div><div><br></div><div>viewController.textField.onValueChanged(example.member#set)<br><br>Etc.<br><br>The "#" notation is just a placeholder for "whatever mechanism is decided upon", though it does seem to be available and using it postfix makes a first-glance sense to me in terms of the semantics of expressions.<br><br>Mike</div></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=6ZGE61OxINd5lLe2xYh9Ku-2BXbixWNr2nvfzp2IB1sZh6tc4kNzfJcSTqpLpEpH526-2BDHnMIJXzBIwTZyK993UjcBHcizeFq0ouH89BEHchKyyDVYPv-2F03mof502YPS9lhbAWBeAhS-2Fu2v8-2BwutM-2FO2Epc1GCFAfJPwBGKc0YwjDX8IVV4On-2F34K2PM7RgUGXNTTX1VqCS3MEhBYrDQJDfB-2F0FVymTzFL3UbyYGnFgYI-3D" alt="" width="1" height="1" border="0" style="min-height:1px!important;width:1px!important;border-width:0!important;margin-top:0!important;margin-bottom:0!important;margin-right:0!important;margin-left:0!important;padding-top:0!important;padding-bottom:0!important;padding-right:0!important;padding-left:0!important">
<br></div></div>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=1p9Jer2O6jVE9KWvo-2B9iUaEyN8slp4IizyiLwsfp54PEP1k3HuN7Q-2FAJKrF227ugqk4jUa030yyR7GFlXlLYzikP14xh5x6W2mSnFWhM2sRqtYV02AGXyRukE4KDh8tGo-2FJlDAp2PjnHKWVCngRHt-2BAbjQWeorNG5xME4E87CTrOc2mTa4quf2LJSP03y8sUIF7NyYL4JnD39lvZQx8chCYT87ynxgZBWUcuhrB7xLw-3D" alt="" width="1" height="1" border="0" style="min-height:1px!important;width:1px!important;border-width:0!important;margin-top:0!important;margin-bottom:0!important;margin-right:0!important;margin-left:0!important;padding-top:0!important;padding-bottom:0!important;padding-right:0!important;padding-left:0!important">
<br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div>