[swift-evolution] Proposal: Expose getter/setters in the same way as regular methods

[ilya]

> 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> 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> 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
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> 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/cb37a931/attachment.html>