After some discussion, it seems to me that the (newly renamed) invokeDynamic method on the Dynamic trait should actually be named a bit more in line with what it's doing. As Charles Nutter points out, it's not really true dynamic dispatch, it's really just an intercept for method failure. In fact, it's exactly what method_missing does in Ruby and doesNotUnderstand in Smalltalk. So in other words, there are a few languages out there that already have a feature very much like this one. And while there is no standard for the naming, the convention is to imply the catching of an unhandled message. This is not at all what "invokeDynamic" implies (particularly in light of JSR-292 and the potential confusion there).
You're still not doing a dynamic invocation at the call site, you're
doing a static invocation of a specific method name with a symbol and
a set of arguments. Whether the resulting target object/proxy
eventually does its own "real" dynamic invocation or not is beside the
point. Because of that I find the invokeDynamic name misleading. It's
invokeByName at best.
I appreciate making dynlang integration better, but calling the target
method invokeDynamic is very misleading, since it isn't "invoke
dynamic".
How about invokeSymbolic? Then it's clear this isn't doing a dynamic
> I agree that calling the method invokeDynamic might suggest too strongly
> that this is always the same as the instruction. On the other hand, I want
> to keep dynamic in the name, also because the method lives in the Dynamic
> trait. So I think we could rename to `applyDynamic'. What do you think about
> that?
invocation but a symbolic one. It's also far less likely to conflict
with any existing libraries/languages that might have "invokeDynamic"
as a method already (as JRuby does in some places).
How about invokeSymbolic? Then it's clear this isn't doing a dynamic
invocation but a symbolic one. It's also far less likely to conflict
with any existing libraries/languages that might have "invokeDynamic"
as a method already (as JRuby does in some places).
For me, invokeDynamic/applyDynamic is an invocation of a method where I do not know the precise method signature (or: on the implementation level: vtable entry), nor do I know whether that specific method is actually implemented on the receiver.
I think invokeDynamic would be a reasonable name for this, were it not
already associated with the existing JSR. If you make a conscious
decision to move away from that, applyDynamic seems reasonable to me,
given the existing use of 'apply'.
I would also like folks to consider what other features of regular
Scala function application might be brought to dynamic invocations.
These seem useful, perhaps on a opt-in basis:
- argument names
- by-name evaluation
- return type other than Dynamic
Marginally useful:
- type arguments (converted to manifests?)
- sequence arguments
-jason
How about invokeSymbolic? Then it's clear this isn't doing a dynamic
invocation but a symbolic one. It's also far less likely to conflict
with any existing libraries/languages that might have "invokeDynamic"
as a method already (as JRuby does in some places).
I could get behind invokeSymbolic. It's certainly more accurate than invokeDynamic. However, I keep getting stuck on the fact that this is a fallback dispatch mechanism from Scala's perspective. Even if the primary purpose is dynlang integration, the feature design needs to be focused on Scala. Again, while it may be the first-line dispatch when calling into the dynlang, it's still the second-line dispatch when making a Scala call.
For me, invokeDynamic/applyDynamic is an invocation of a method where I do not know the precise method signature (or: on the implementation level: vtable entry), nor do I know whether that specific method is actually implemented on the receiver.
If we were calling that method directly, then yes, I could sort of see your point. However, the Dynamic API is not directly exposed to the call site. It's only an artifact of the receiver, which can then choose to handle it in whatever way is required (a way which may in fact be static, not dynamic). So, thinking from an API consumer's perspective (and remember, the API consumer here is the one implementing the method in Dynamic), the "Dynamic" part of the method name doesn't really make any sense.
Daniel
On Jan 28, 4:00 pm, martin odersky <martin.oder...@epfl.ch> wrote:
<snip/>
> Or wrap in proxies, yes. Ideally, the dynamic language we interact with
>
> implements Scala's Dynamic type. As long as that does not happen we need to
> go though proxies.
It will be almost impossible for most languages to do this without
yanking in a Scala dependency for all users all the time. Perhaps this
should be spun off into a common library without any language-specific
dependencies?
I think this is a huge point that we shouldn't miss. If we want to interop with dyn languages on the JVM, the 'core' library should consist of a single/set of standalone interface(s) that dyn languages can pull in as a separate JAR dependency. This dependency could be small and simple and gives us a decent migration strategy where the dyn-lang interface wouldn't be easily broken by new scala-libraries.
But you need to see both the dynamic and static perspective. It's perfectly possible that an object that has a certain method, say, "foo", has static type "Dynamic". So statically, "foo" is invisible, but it is still present. That's why I believe that "missingMethod" is confusing. The method is not missing at all, it's just invisible for the static typechecker. If you want a painfully long name you could pick "methodStaticallyInvisibleNowTryAppliyDynamic", but I believe we all prefer "applyDynamic" over that.