[swift-evolution] Proposal: Expose getter/setters in the same way as regular methods
Pierre Monod-Broca
pierre at monod-broca.fr
Mon Dec 14 02:25:39 CST 2015
+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 at 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 at swift.org <mailto:swift-evolution at 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 at swift.org <mailto:swift-evolution at 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 at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <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 <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 <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/6e8d549c/attachment.html>
More information about the swift-evolution
mailing list