Mostly as a matter of historical interest:
The hard-coding of collection operators for KVC in Cocoa was more of a scope of
documentation or API style decision than anything. The original implementation
of KVC came from Enterprise Objects Framework (which then became WebObjects),
and in both of those frameworks collection operators could be added just by
implementing correctly named category methods on NSArray/NSSet. I.e. the
implementation of valueForKeyPath: constructed a selector from the part
following the ‘@‘ and checked to see if it existed.
- Greg
> On Apr 6, 2017, at 9:46 PM, John McCall via swift-evolution
> <[email protected]> wrote:
> I'm not seriously endorsing this exact spelling. It would be much better to
> be able to write something like:
> \Department.employees.sum(of: \.salary)
> However, since "sum" would presumably be a method on Collection, I think this
> would have to be a future extension to the proposal, and the overall thing
> might have to be a function rather than a key path because it would no longer
> have identity.
>
> Also, I do feel obliged to note that AppKit/Cocoa's "very expressive" way of
> doing this is a small number of hard-coded operators, whereas even the
> kindof-unfortunate subscript trick would be arbitrarily extensible.
>
> John.
>
>
>>
>> Thanks.
>>
>>>
>>> ...
>>>
>>> \Department.employees[summing: \.salary]
>>>
>>> That's not actually a good name for the subscript, but maybe there's one
>>> out there.
>>>
>>> John.
>>>
>>>>
>>>> Also, in this example:
>>>>
>>>> let firstFriendsNameKeyPath = \Person.friends[0].name
>>>> let firstFriend = luke[keyPath: firstFriendsNameKeyPath] // "Han Solo"
>>>>
>>>> Can't we do without the keyPath: argument name? The compiler knows it's a
>>>> keypath, it would be nicer to write
>>>>
>>>> let firstFriend = luke[firstFriendsNameKeyPath] // "Han Solo"
>>>>
>>>>> On Apr 5, 2017, at 16:56 , Douglas Gregor via swift-evolution
>>>>> <[email protected]> wrote:
>>>>>
>>>>> Hello Swift community,
>>>>>
>>>>> The second review of SE-0161 "Smart KeyPaths: Better Key-Value Coding for
>>>>> Swift" begins now and runs through April 9, 2017. The revised proposal is
>>>>> available here:
>>>>>
>>>>> https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md
>>>>> The core team’s feedback from the first review of this proposal can be
>>>>> viewed at:
>>>>>
>>>>> https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000342.html
>>>>> Reviews are an important part of the Swift evolution process. All reviews
>>>>> should be sent to the swift-evolution mailing list at
>>>>>
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>> or, if you would like to keep your feedback private, directly to the
>>>>> review manager. When replying, please try to keep the proposal link at
>>>>> the top of the message:
>>>>>
>>>>> Proposal link:
>>>>>
>>>>> https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md
>>>>> Reply text
>>>>> Other replies
>>>>> What goes into a review?
>>>>>
>>>>> The goal of the review process is to improve the proposal under review
>>>>> through constructive criticism and, eventually, determine the direction
>>>>> of Swift. When writing your review, here are some questions you might
>>>>> want to answer in your review:
>>>>>
>>>>> • What is your evaluation of the proposal?
>>>>> • Is the problem being addressed significant enough to warrant a change
>>>>> to Swift?
>>>>> • Does this proposal fit well with the feel and direction of Swift?
>>>>> • If you have used other languages or libraries with a similar feature,
>>>>> how do you feel that this proposal compares to those?
>>>>> • How much effort did you put into your review? A glance, a quick
>>>>> reading, or an in-depth study?
>>>>> More information about the Swift evolution process is available at
>>>>>
>>>>> https://github.com/apple/swift-evolution/blob/master/process.md
>>>>> Thank you,
>>>>>
>>>>> -Doug
>>>>>
>>>>> Review Manager
>>>>>
>>>>> _______________________________________________
>>>>> swift-evolution mailing list
>>>>> [email protected]
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>
>>>>
>>>> --
>>>> Rick Mann
>>>> [email protected]
>>>>
>>>>
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> [email protected]
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>> --
>> Rick Mann
>> [email protected]
>>
>>
>
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
