Key-Paths do support operators and custom functions. How should this work within the context of this proposal?
2016-04-12 11:14 GMT+02:00 Brent Royal-Gordon via swift-evolution < [email protected]>: > > I very much like this proposal but what bothers me is this doubling of > valueForKeyPath(#keyPath(xxx) in the signature of the function. > > > > chris.valueForKeyPath(#keyPath(Person.bestFriend.lastName)) // => Groff > > > > chris > > .valueForKeyPath(#keyPath(Person.friends.firstName)) // => ["Joe", > "Douglas"] > > > > I’m not sure whether the form below is actually possible. For me it > reads more naturally and is more consistent with “Modern Swift” as far as I > know. > > > > chris.valueFor(#keyPath(Person.friends.firstName)) // => ["Joe", > "Douglas”] > > or maybe > > chris.valueOf(#keyPath(Person.friends.firstName)) // => ["Joe", > "Douglas”] > > Interesting. > > If Foundation, Core Data, AppKit, and other frameworks properly annotated > their APIs, I think we could actually get this from the already accepted > SE-0033 "Import Objective-C Constants as Swift Types" < > https://github.com/apple/swift-evolution/blob/master/proposals/0033-import-objc-constants.md>. > Specifically, Foundation would have to include this typedef: > > typedef NSString * NSKeyPath > __attribute__((swift_wrapper(struct))); > > And all APIs with string types which were actually key paths would have to > be modified to use it. Then `-(nullable > id)valueForKeyPath:(NSKeyPath)keyPath` would import as `func value(for: > NSKeyPath) -> AnyObject?`. This proposal's `#keyPath` construct would have > to then construct an `NSKeyPath` instead of a `String`. > > (To make this all work, it might make sense to add a > KeyPathLiteralConvertible protocol to the standard library. As a bonus, if > this protocol's initializer received enough metadata, it might be able to > construct alternate forms of key paths, such as the Rails-style ones which > handle arrays somewhat differently from Foundation's.) > > This is more work, but it's also more general, which is a pretty cool > prospect! > > -- > Brent Royal-Gordon > Architechies > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > -- Mit freundlichen Grüßen *Christian Kienle* Mobile Developer *REWE Digital GmbH* Domstraße 20, 50668 Köln, Büro: Schanzenstr. 6-20, 51063 Köln Geschäftsführer: Dr. Jean-Jacques Michel van Oosten (Vorsitzender), Christoph Eltze, Dr. Johannes Steegmann, Dr. Robert Zores Handelsregister: Amtsgericht Köln (HRB 78670) UST-ID-Nr.: DE 290 605 450 Telefon: +49 151 11441782 E-Mail: [email protected] Internet: *www.rewe-digital.com <http://www.rewe-digital.com/>* Ein Unternehmen der *REWE GROUP* http://www.rewe-group.com
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
