On 2008.05.13., at 16:13, helge wrote: > On 13 Mai, 16:05, Attila Szegedi <[EMAIL PROTECTED]> wrote: >> Sure. The compiler always chooses the most specific of all applicable >> methods. Both (Object) and (String) are applicable to (null), but >> (String) is more specific, because String extends Object. If you >> had a >> third override, i.e. isNotEmpty(Integer), you'd get a compiler error >> as both (Integer) and (String) would be applicable, but neither is >> more specific than the other. > > 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. > But > OK, the compiler usually doesn't have the knowledge in advance. Though > Rhino deals with it at call time anyways. And what additional type knowledge does Rhino have about null at runtime? > So are there chances that this is added to Rhino? :-) Hm... Rhino is supposed to have overloaded method resolution, isn't it? 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. If Rhino would just rely on my JavaBeans MOP implementation (as seen on <http://dynalang.svn.sourceforge.net/viewvc/dynalang/trunk/mop/src/org/dynalang/mop/beans/ >, see various "Overloaded*.java" files) , then it'd be solved once and for all. Attila. > Thanks, > Helge _______________________________________________ dev-tech-js-engine-rhino mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
