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.
On Nov 20, 2017, at 10:07 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:
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.
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@swift.org> wrote:
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.
I have several questions/issues in this new iteration:
• Why does DynamicCallableWithKeywordsToo inherit from DynamicCallable? For an interop layer for Python-style languages, we would be interested in providing conformance to DynamicCallableWithKeywordsToo (like you did in your example), but that would force us to provide an implementation for the keyword-less function that just calls the other overload with empty labels. Seems unnecessary.
• Why is the DynamicCallableKeywordedMethod protocol not included with the two others? The way it is presented in the proposal, it almost feels like an afterthought and not a full-fledged part of the proposal.
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.
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.
···
On 22 Nov 2017, at 09:10, Alex Hoppen via swift-evolution <swift-evolution@swift.org> wrote:
– Alex
On 21. Nov 2017, at 07:07, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:
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.