[swift-evolution] [Pitch] Introduce User-defined "Dynamic Member Lookup" Types

[Chris Lattner]

On Nov 15, 2017, at 2:52 PM, Jean-Daniel via swift-evolution <swift-evolution at swift.org> wrote:
> Just a question about what it mean for API resilience. Actually, adding a property to an existing class is not a breaking change. 
> 
> For a class that implements that protocol, as it will be possible to use property accessor with any non existing property. Adding a new property to this class will now change the class behavior in unexpected way as the old client will still call the dynamic lookup method, but new code will use the new accessor method. Is it something that should be mention in the «  Effect on API resilience » section ?

Right.  Sure, I’ll add a mention of that.

-Chris


> 
> 
>> Le 15 nov. 2017 à 08:29, Chris Lattner via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> a écrit :
>> 
>> Hi All,
>> 
>> As a peer to the DynamicCallable proposal (https://gist.github.com/lattner/a6257f425f55fe39fd6ac7a2354d693d <https://gist.github.com/lattner/a6257f425f55fe39fd6ac7a2354d693d>), I’d like to get your feedback on making member lookup dynamically extensible.  My primary motivation is to improve interoperability with dynamic languages like Python, Perl, Ruby, Javascript, etc, but there are other use cases (e.g. when working with untyped JSON).
>> 
>> In addition to being a high impact on expressivity of Swift, I believe an implementation can be done in a way with changes that are localized, and thus not have significant impact on the maintainability of the compiler as a whole.  Once the pitch phase of this proposal helps refine the details, I’ll be happy to prepare an implementation for consideration.
>> 
>> In case it is useful, I’m working on cleaning up my current prototype Python bindings.  I’ll share them in the next day or two in case they are useful to provide context.  It is amazingly simple: less than 500 lines of Swift code (plus some small additional C header glue to work around clang importer limitations) enables impressive interoperability.  The only problems are the verbosity addressed by this proposal and the peer DynamicCallable proposal.
>> 
>> 
>> Here is the canonical proposal URL:
>> https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438 <https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438>
>> 
>> A snapshot of the proposal is included below in case it is useful.  Thanks in advance for help improving the proposal!
>> 
>> -Chris
>> 
>> 
>> Introduce User-defined "Dynamic Member Lookup" Types
>> 
>> Proposal: SE-NNNN <https://gist.github.com/lattner/NNNN-DynamicMemberLookup.md>
>> Author: Chris Lattner <https://github.com/lattner>
>> Review Manager: TBD
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171115/4ae68de1/attachment.html>