> On 22 Nov 2017, at 09:10, Alex Hoppen via swift-evolution > <swift-evolution@swift.org> wrote: > > 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.
That’s true, but what about access to properties? The proxy object would have to lazily call property getters, which could result in unexpected behaviour. > – Alex > >> On 21. Nov 2017, at 07:07, Chris Lattner via swift-evolution >> <swift-evolution@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@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
