[swift-evolution] [Draft] Obejctive-C Keypaths

[Félix Cloutier]

I think that using something like #keypath would be safer and more refactor-friendly than bare strings, but is KVC going to be an important part of Swift's future?

Félix

> Le 4 mars 2016 à 12:05:05, David Hart via swift-evolution <swift-evolution at swift.org> a écrit :
> 
> Hello Swift-friends,
> 
> After more thinking, here is a new proposal, based on my original proposal for #selector for properties but better targeted at the intended use: referencing key-paths. Please let me know what you think:
> 
> Referencing Objective-C key-paths
> 
> Proposal: SE-XXXX <https://github.com/apple/swift-evolution/blob/master/proposals/XXXX-objc-keypaths.md>
> Author(s): David Hart <https://github.com/hartbit>
> Status: TBD
> Review manager: TBD
>  <https://github.com/hartbit/swift-evolution/tree/objc-keypaths#introduction>Introduction
> 
> In Objective-C and Swift, key-paths used by KVC and KVO are represented as string literals (e.g., "friend.address.streetName"). This proposal seeks to improve the safety and resilience to modification of code using key-paths by introducing a compiler-checked expression.
> 
>  <https://github.com/hartbit/swift-evolution/tree/objc-keypaths#motivation>Motivation
> 
> The use of string literals for key paths is extremely error-prone: there is no checking that the string corresponds to a valid key-path. In a similar manner to the proposal for the Objective-C selector expression SE-0022 <https://github.com/apple/swift-evolution/blob/master/proposals/0022-objc-selectors.md>, this proposal introduces a syntax for referencing compiler-checked key-paths. When the referenced properties and methods are renamed or deleted, the programmer will be notified by a compiler error.
> 
>  <https://github.com/hartbit/swift-evolution/tree/objc-keypaths#proposed-solution>Proposed solution
> 
> Introduce a new expression #keypath that allows one to build a String from a key-path:
> 
> class Person: NSObject {
>     dynamic var firstName: String = ""
>     dynamic var lastName: String = ""
>     dynamic var friends: [Person] = []
>     dynamic var bestFriend: Person?
> 
>     init(firstName: String, lastName: String) {
>         self.firstName = firstName
>         self.lastName = lastName
>     }
> }
> 
> let chris = Person(firstName: "Chris", lastName: "Lattner")
> let joe = Person(firstName: "Joe", lastName: "Groff")
> let douglas = Person(firstName: "Douglas", lastName: "Gregor")
> chris.friends = [joe, douglas]
> chris.bestFriend = joe
> 
> 
> #keypath(Person.firstName) // => "firstName"
> chris.valueForKey(#keypath(Person.firstName)) // => Chris
> #keypath(Person.bestFriend.lastName) // => "bestFriend.lastName"
> chris.valueForKeyPath(#keypath(Person.bestFriend.lastName)) // => Groff
> #keypath(Person.friends.firstName) // => "friends.firstName"
> chris.valueForKeyPath(#keypath(Person.friends.firstName)) // => ["Joe", "Douglas"]
> By having the #keypath expression do the work to form the Objective-C key-path string, we free the developer from having to do the manual typing and get static checking that the key-path exists and is exposed to Objective-C.
> 
>  <https://github.com/hartbit/swift-evolution/tree/objc-keypaths#impact-on-existing-code>Impact on existing code
> 
> The introduction of the #keypath expression has no impact on existing code as it returns a String. It is simply a modification-safe alternative to using literal strings for referencing key-paths.
> 
>  <https://github.com/hartbit/swift-evolution/tree/objc-keypaths#alternatives-considered>Alternatives considered
> 
> One aspect of the design which seems potentially complicated is the reference to key-paths which include an collection in the middle of the path.
> 
> chris.valueForKeyPath(#keypath(Person.friends.firstName))
> The above example is potentially harder to implement because the argument of #keypath is not a valid Swift expression, compared to the other two examples. An alternative would be to remove the ability to reference those key-paths, making the proposal less useful, but easier to implement.
> _______________________________________________
> 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/20160304/0199f20f/attachment.html>