FYI, I just sent a proposal draft titled “Generalized Naming for Any Function” that pulls these ideas together more formally. I went with a different syntax that I’d been kicking around for a while internally, and I’d love to hear everyone’s thoughts on this.
- Doug > On Dec 14, 2015, at 12:25 AM, Pierre Monod-Broca via swift-evolution > <swift-evolution@swift.org> wrote: > > +1 > > I like the #get, #set suffixes. > > I’m afraid the following would be a bit ambiguous >> - example.init(argument:Int, another:String) >> - example.subscript(index:Int) > > Maybe with ‘#’ too > - example.init#argument:Int#another:String > - example.init#argument#another > - example.init#(argument:Int, another:String) > - example.subscript#index:Int > - example.subscript#Int > > Pierre > >> Le 14 déc. 2015 à 08:57, ilya via swift-evolution <swift-evolution@swift.org >> <mailto:swift-evolution@swift.org>> a écrit : >> >> > Being able to refer to getters and setters is a good idea and aligns with >> > being able to refer to initializers and methods. >> > I would also add subscripts to the list if possible. >> >> Great idea! Let's discuss syntax >> >> How about >> - example.get.member >> - example.set.member >> - example.init(argument:Int, another:String) >> - example.subscript(index:Int) >> >> >> On Mon, Dec 14, 2015 at 3:49 AM, Marc Knaup via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> Wait, where is stated that KVO is a long-term goal for Swift? I might have >> missed that. >> >> 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. >> >> I prefer explicit integration points like closures, delegates and alike. >> 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. >> >> 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. >> >> >> But I'm getting off-topic since your discussion is not about KVO nor about >> KVC. >> >> Being able to refer to getters and setters is a good idea and aligns with >> being able to refer to initializers and methods. >> I would also add subscripts to the list if possible. >> >> On Mon, Dec 14, 2015 at 1:34 AM, Michael Henson via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> 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: >> >> class Example { >> var member: String >> >> func print() { >> print(self.member) >> } >> } >> >> var example = Example(member: "Hi!") >> >> var example_print_method = example.print >> example_print_method() >> result: >> Hi! >> >> 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: >> >> var serializeFields = [ >> "member": example.member#get, >> ] >> >> var deserializeFields = [ >> "member": example.member#set, >> ] >> >> var broadcastValueTo = [ >> "memberValues": [ >> example.member#set, >> example2.member#set, >> example3.member#set, >> ] >> ] >> >> viewController.textField.onValueChanged(example.member#set) >> >> Etc. >> >> 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. >> >> Mike >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution