On 3/20/02 11:07 AM, "Attila Szegedi" <[EMAIL PROTECTED]> wrote:
> I have looked at the algorithm with which Vel selects among overloaded > methods. It is unfortunately kludgy, overcomplicated, and -- which is the > biggest problem -- incomplete. It has a FIXME comment that it should be > improved to deal with interfaces. Also, it doesn't honor the fact that in > reflective method calls an argument of primitive type is represented by an > object of the corresponding object type, so a java.lang.Boolean can be > passed to a method that expects primitive boolean. There are also widening > primitive conversions that should be taken into account when selecting the > correct overloaded method (a java.lang.Integer can be passed wherever a > primitive int can be passed, and that includes methods that expect primitive > int, long, float, and double parameters due to widening conversions). > > The JLS has a very clear algorithm (described in section 15.12.2, amended by > section 5.3) for selecting the most specific applicable method from all > available overloaded methods. I have implemented that algorithm few days > back in Freemarker, it works like champ and actually deals with interfaces, > primitive-to-object assignments and primitive widening conversions. Beside, > the code turned out to be quite elegant as well. > > I would be happy to rework Velocity's overloaded method selector as well if > there's a need for it. Note that this is not a "don't fix if it ain't > broken" situation since I consider it *is* broken in the sense that there > are situations described above it just doesn't handle. > > Opinions? Go for it -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting "He who throws mud only loses ground." - Fat Albert -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
