> On Mar 17, 2017, at 2:43 PM, Matthew Johnson via swift-evolution
> <[email protected]> wrote:
>
>>
>> On Mar 17, 2017, at 3:42 PM, Joe Groff via swift-evolution
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>> I hope that Mirror will ultimately be superseded by key paths:
>>
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170313/033998.html
>>
>> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170313/033998.html>
>>
>> Key paths address the mutability limitations of mirror, and give you the
>> ability to work with arbitrary values in a dictionary-like way that Mirror
>> does without an intermediary type. While the initial key path proposal lacks
>> the dynamic discovery of key paths by name/index/etc., that would be a
>> natural future direction to go in. Being able to build or query key paths
>> dynamically would also solve other problems with Mirror, such as not being
>> able to discover the structure of a value without an instance of the value.
>
> This all sounds so incredible! I’m really looking forward to dynamic
> discovery and manipulation of key paths, especially without needing an
> instance of the type to do it. It can’t come soon enough - I already have a
> project where it could come in very handy!
+1. I have a project right now that could use this tomorrow (and another one
which is on hold until something like this becomes available).
The project I am working on now would use it for auto-generating user
interfaces (right now I need to use getter & setter closures). The one on hold
would use it for hooking together parts of the event system (basically I need
KVO, but made it using Protocol-oriented design… which was great until I
realized I needed KVO).
Thanks,
Jon
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution