On 2007.12.07., at 21:06, Jochen Theodorou wrote:
> If we now have these methods: > > def foo(String s) > def foo(GString s) > > then your common type would be String, because we handle GString as > String, then we would coerce the GString to String and in the we would > call the String method... That would be strange, because our call was > with a GString object, so we intend to call the GString method. If > we go > with the rules of the java class system, then the common type would be > Object I guess, not sure if you use interfaces... anyway, in case of > Object no coercion would happen... Which means that if you invoked foo with a GString, it would remain a GString and match the foo(GString signature). If you invoked it with String, then it'd match foo(String) signature. This most common supertype thingie is there to allow for automatic conversions where they can be performed unambiguously. It kicks in much less frequently than you'd think. If all overloads specify the same type for an argument, then that type is used. Otherwise it pretty quickly degenerates into java.lang.Object, basically preventing automatic type conversions from happening. In these cases, it is really ambiguous and is best left to the programmer to explicitly specify the conversion. > looks like I still don't get this > common type thing. Start from a non-overloaded method, say foo(boolean, String) it is clear that the first argument to the method should be converted to a boolean, and the second to a string on invocation, right? If the calling language contains legal automatic type conversions from actual argument types to these types, they should be performed. I.e. if the language supports 0->false conversion, then a foo(0, 0) would end up being automatically translated to foo(false, "0"). A call to foo(0, new Array[]) might result in something like foo(false, "[]") or foo(false, "Array[...]"), or whatever is the conversion from an array object to string in the source language. Now, If you add an overload: foo(boolean, Integer) the common types become [boolean, Object] Now, if you invoke (0, 0) from a language that allows 0->false conversion (Python and JavaScript are typical examples), then the first argument can still be automatically converted to boolean. The second argument can not be automatically converted to anything, so this invocation will match foo(boolean, Integer). If you attempt foo(0, ""), that'll nicely match foo(boolean, String). However, foo(0, new Array()) will now fail, as the array is neither a String nor an Integer, and the ambiguity between possible overloads will prevent either conversion. Therefore, this whole common supertype business for overloaded methods' parameters (maintained by arity, mind you, so two-arg methods don't interfere with three-arg methods and so forth) is used only for bookkeeping of maximal allowed automatic type conversions, nothing more. > which reminds me what happens if the signature contains an interface? It works as you'd expect. Well, as I'd expect, at least :-). I refer to "types" throughout and not to "classes" or "interfaces". The "most specific common supertype" concept applies to interfaces as well. In a previous e-mail I said that foo(List) foo(Set) will cause the common supertype to be Collection. If the two interfaces are completely independent, or they have more than one maximally specific common interface[*] it'll again fall back to java.lang.Object. [*] as in: interface D extends A,B interface C extends A,B and A and B are independent, then most specific common supertype for C and D is java.lang.Object as both A and B would be maximally specific. > bye blackdrag > > > -- > Jochen "blackdrag" Theodorou > The Groovy Project Tech Lead (http://groovy.codehaus.org) > http://blackdragsview.blogspot.com/ > http://www.g2one.com/ Attila. -- home: http://www.szegedi.org weblog: http://constc.blogspot.com --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
