On Dec 7, 2007 2:22 PM, Jochen Theodorou <[EMAIL PROTECTED]> wrote: > > Attila Szegedi schrieb: > > then the target types for argument conversion for all 2-arg overloads > > of foo will be computed to be [java.lang.String, > > java.util.Collection]. When the method is dynamically invoked, the > > passed callProtocol will be asked to provide a representation of the > > first method as if it were a String, and to provide a representation > > of the second method as if it were a Collection. Hopefully in the real > > invocation, the second argument will already be either a list or a > > set, so it will be returned unchanged. If it is however a collection > > that is neither a list nor a set, then no method will be invoked and > > an error will be thrown. > > that is different from what we do in Groovy, because in Groovy we > "convert" just before the call and there will be no error, because > invalid choices are already removed.No I guess what you mean is getting > the argument types... ehm.. no again... why should the arguments depend > on the unified method parameter types? Why not add a method that checks > if a parameter is assignable to an argument and let the language decide > how it should behave here. Then you might still need a coercion step > before the call, but here again I would let the language plug in.
I think that you riase an important point. In dynamic languages which allow classes to convert themselves to other types you have to take this ability into account when selecting the appropriate method to dispatch. I have already explained that the Ng runtime asks each method object for the cost of making the call given a set of parameters. The method object does this by asking the MetaClass for each of the parameters "how much would it cost you to convert yourself to this type?" and accumulating the costs (in fact we don't pass the actual parameters to the method object we pass the MetaClasses for each of the actual parameters - this way we support typed as well as untyped actual parameters). This means that the method selection rules are not wired into the runtime at all. In general you can't just look at the type of a value and decide if it can be converted to another type. Also, in a dynamic language, the ability to convert from one type to another can appear or disappear at will. In Ng it's quite conceivable that I can convert C to D in one thread and not be able to do it at exactly the same time in another. I'm not quite sure how groovy does coercion these days but I suspect it's the same. John Wilson --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en -~----------~----~----~----~------~----~------~--~---
