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

[Javier Soto]

One thing to be aware of is the lifetime semantics. This is something that
has bit me in the past when using object.functionName and passing that to
another object that holds on the function: it will actually hold a strong
reference to object! So it's easy to see how one can create retain cycles
that way, and it's not obvious at all when reading the code (IMO)
On Wed, Dec 16, 2015 at 1:07 AM Adrian Kashivskyy via swift-evolution <
swift-evolution at swift.org> wrote:

> +1, I like this idea! I'm not sure if I like `#`, though – maybe the type
> should be inferred, much like when using `init`s?
>
> struct Foo {
> init(_: Int) {}
> init(_: String) {}
> }
>
> // this infers the int setter
> let intInit: (Int) -> Foo = Foo.init
>
> // this infers the string setter
> let stringInit: (String) -> Foo = Foo.init
>
>
> Note that you cannot explicitly refer to a specific `init`. My proposal is
> to use the same technique when referring to getters and setters:
>
> struct Foo {
> let bar: Int
> }
>
> // this just reads the value
> let value = Foo.bar
>
> // this infers a getter
> let getter: () -> Int = Foo().bar
>
> // this infers a setter
> let setter: (Int) -> Void = Foo().bar
>
>
> Pozdrawiam – Regards,
> Adrian Kashivskyy
>
> Wiadomość napisana przez Pierre Monod-Broca via swift-evolution <
> swift-evolution at swift.org> w dniu 14.12.2015, o godz. 09:25:
>
>
> +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> 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
>>
>>
>  _______________________________________________
> 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
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-- 
Javier Soto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151217/e1c195ee/attachment.html>