> 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

Reply via email to