Proposal: Expose getter/setters in the same way as regular methods

Evolution Discussion
5

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> 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> 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
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution