You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by Attila Szegedi <sz...@freemail.hu> on 2002/03/20 17:07:43 UTC
Overloaded method selection
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?
--
Attila Szegedi
home: http://www.szegedi.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Overloaded method selection
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 3/22/02 7:46 AM, "Attila Szegedi" <sz...@freemail.hu> wrote:
> Attached is the MethodMap.java that in its find() method uses the algorithm
> specified in JLS for finding the most specific applicable method among
> overloaded methods for given actual parameter types. (with the known caveat
> that it can't distinguish object from primitive types (ie. java.lang.Integer
> from int) since -- this being reflection -- it always recieves object, and
> never primitive parameters. Therefore, the
>
> foo(Integer i)
>
> and
>
> foo(int i)
>
> method signatures are ambigous when foo is called with a java.lang.Integer.
> We could discuss whether we optionally favor primitive over object types (or
> other way round) in this case instead of declaring ambiguity.
>
> I've run the test suite against the new code (with special attention to
> IntrospectorTestCase and IntrospectorTestCase2), and after several trivial
> bugfixes it now works correctly. To be completely frank, the template
> encoding test actually failed but I don't think it has to do anything with
> my code.
>
> It needs review from a committer (and hopefully a commit).
Thanks! I'll look at it on the plane back.
>
> BTW, what on the Earth is a Twonk?
A generic thingy.
:)
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
The question is : What is a Mahnamahna?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Overloaded method selection
Posted by Attila Szegedi <sz...@freemail.hu>.
Attached is the MethodMap.java that in its find() method uses the algorithm
specified in JLS for finding the most specific applicable method among
overloaded methods for given actual parameter types. (with the known caveat
that it can't distinguish object from primitive types (ie. java.lang.Integer
from int) since -- this being reflection -- it always recieves object, and
never primitive parameters. Therefore, the
foo(Integer i)
and
foo(int i)
method signatures are ambigous when foo is called with a java.lang.Integer.
We could discuss whether we optionally favor primitive over object types (or
other way round) in this case instead of declaring ambiguity.
I've run the test suite against the new code (with special attention to
IntrospectorTestCase and IntrospectorTestCase2), and after several trivial
bugfixes it now works correctly. To be completely frank, the template
encoding test actually failed but I don't think it has to do anything with
my code.
It needs review from a committer (and hopefully a commit).
BTW, what on the Earth is a Twonk?
--
Attila Szegedi
home: http://www.szegedi.org
Re: Overloaded method selection
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 3/21/02 3:21 AM, "Attila Szegedi" <sz...@freemail.hu> wrote:
> I swear I *didn't* look at the JavaDoc @author tag before qualifying that
> code, so it's an unbiased opinion :-)
Of *course* you didn't :)
I am using the introspector for another project, and found some problems -
was going to go in and review this stuff, but if you have the time...
geir
>
>
> ----- Original Message -----
> From: "Geir Magnusson Jr." <ge...@optonline.net>
> To: "Velocity Developer's List" <ve...@jakarta.apache.org>
> Sent: Wednesday, March 20, 2002 5:17 PM
> Subject: Re: Overloaded method selection
>
>
>>
>>
>> (BTW : that was my kludgy, overcomplicated and incomplete solution... :)
>>
>> --
>> Geir Magnusson Jr. geirm@optonline.net
>> System and Software Consulting
>> The bytecodes are language independent. - Sam Ruby
>>
>>
>> --
>> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
>> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>>
>>
>>
>>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"They that can give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety." - Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Overloaded method selection
Posted by Attila Szegedi <sz...@freemail.hu>.
I swear I *didn't* look at the JavaDoc @author tag before qualifying that
code, so it's an unbiased opinion :-)
----- Original Message -----
From: "Geir Magnusson Jr." <ge...@optonline.net>
To: "Velocity Developer's List" <ve...@jakarta.apache.org>
Sent: Wednesday, March 20, 2002 5:17 PM
Subject: Re: Overloaded method selection
>
>
> (BTW : that was my kludgy, overcomplicated and incomplete solution... :)
>
> --
> Geir Magnusson Jr. geirm@optonline.net
> System and Software Consulting
> The bytecodes are language independent. - Sam Ruby
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Overloaded method selection
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 3/20/02 11:15 AM, "Geir Magnusson Jr." <ge...@optonline.net> wrote:
> On 3/20/02 11:07 AM, "Attila Szegedi" <sz...@freemail.hu> 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
(BTW : that was my kludgy, overcomplicated and incomplete solution... :)
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
The bytecodes are language independent. - Sam Ruby
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Overloaded method selection
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 3/20/02 11:07 AM, "Attila Szegedi" <sz...@freemail.hu> 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. geirm@optonline.net
System and Software Consulting
"He who throws mud only loses ground." - Fat Albert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>