[swift-evolution] SE-0062 Referencing Objective-C key-paths

[Christian Kienle]

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 <
swift-evolution at swift.org>:

> > 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
> swift-evolution at swift.org
> 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: christian.kienle at rewe-digital.com
Internet: *www.rewe-digital.com <http://www.rewe-digital.com/>*

Ein Unternehmen der *REWE GROUP*
http://www.rewe-group.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160412/a7f0b20e/attachment.html>