[swift-evolution] [Pitch #2] Introduce user-defined dynamically "callable" types

Alex Hoppen alex at alexhoppen.de
Wed Nov 22 02:09:55 CST 2017


Would we really need the dynamicCall(method:arguments:) method and DynamicCallableKeywordedMethod protocol for Smalltalk-like languages? 

I think in these languages, we could achieve keyword-argument-sensitive method dispatch purely based on DynamicMemberLookupProtocol and DynamicCallableWithKeywordsToo as follows:

- The dynamic member lookup returns a proxy object that stores the method name and keeps a reference to the object on which the method shall be called. This proxy conforms to DynamicCallableWithKeywordsToo.
- At method call when the keyword arguments get passed, the proxy object looks the method to be called up (it now has both the method name and all keyword arguments) and immediately calls it.

– Alex

> On 21. Nov 2017, at 07:07, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Hi All,
> 
> I’ve significantly revised the ‘dynamic callable’ pitch, here’s a second edition:
> https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438
> 
> I’ve incorporated a bunch of feedback from the first round of discussion:
> 
> - I’ve significantly increased the motivation section, talking about the value of solving this problem, and explaining why IMO an “ObjC Importer” approach is a bad idea.
> - I’ve made it possible for (e.g.) a Javascript client to implement support for this while statically rejecting keyword arguments, but allow (e.g.) a Python implementation to accept them.
> - I’ve expanded the model to support the name lookup requirements of Ruby and other smalltalk’y languages that require a base name + argument labels be present to resolve calls.
> - I’ve expanded the alternatives section to explain why statically resolvable callables are orthogonal to this proposal and already pretty well served by Swift today.
> - I’ve expanded the alternatives section to talk about F# type providers, explaining why they don’t solve this problem and are an interesting follow-on refinement to consider after taking this proposal (or something like it).
> 
> That said, there is at least one specific obviously bad thing about this proposal: the name “DynamicCallableWithKeywordsToo” which I appreciate help on.
> 
> If you’re interested in this topic, I’d really appreciate it if you’d read the new draft of the proposal.  It is significantly different than the original draft.  I welcome suggestions for improvements to the proposal, and insight into anything that is unclear or insufficiently motivated.
> 
> Thanks!
> 
> -Chris
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution



More information about the swift-evolution mailing list