On 13 Mai, 16:51, Attila Szegedi <[EMAIL PROTECTED]> wrote: > > Hm, that approach looks quite wrong for the special case 'null'. > Why? null is assignable to both Object and String, so both methods are > applicable to it. String is assignable to Object, so it is more > specific, hence it gets called. Makes perfect sense to me.
Why would you call the most specific variant? Since null is most generic, I would expect the most generic method to be called :-) Anyways. > And what additional type knowledge does Rhino have about null at > runtime? It knows that the value is actually null when it decides for a method to call? Java doesn't know that when it chooses the method to be invoked, it only has the static type at compile time (ignoring the special case of a constant 'null'). > > So are there chances that this is added to Rhino? :-) > Hm... Rhino is supposed to have overloaded method resolution, isn't > it? Apparently not (btw: those are just static functions, not constructors): ---snip--- Message: The choice of Java constructor isNotEmpty matching JavaScript argument types (null) is ambiguous; candidate constructors are: boolean isNotEmpty(java.lang.Object) boolean isNotEmpty(java.lang.String) ---snap--- Actually I really don't care which one Rhino would call, Object makes more sense to me, especially if there would be yet another isNotEmpty(Number), but OK. Problem is, in my Java code there are quite a few such overloaded methods which are just there for performance or convenience reasons. > If it doesn't I could probably do it -- I actually have > implemented that twice so far, once for FreeMarker and once for my > generic Dynalang-MOP project. Interesting. Helge _______________________________________________ dev-tech-js-engine-rhino mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
