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
> <[email protected]> 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 <[email protected]
>> <mailto:[email protected]>> 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
>> <[email protected] <mailto:[email protected]>> 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
>> <[email protected] <mailto:[email protected]>> 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
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> swift-evolution mailing list
> [email protected] <mailto:[email protected]>
> https://lists.swift.org/mailman/listinfo/swift-evolution
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
