Re: finding method efficiently
Robert == Robert Schuster [EMAIL PROTECTED] writes:
Robert Now when evaluating the XML data I have to search the method put
Robert which accepts the two arguments. Having
Robert only String and JFrame as argument types means that the call to
Robert HashMap.class.getMethod(put, new Class[] { String.class,
Robert JFrame.class });
Robert will fail. My current naive approach to find HashMap.put(Object,
Robert Object) is to generate a long list of a superclasses and
Robert interfaces of all arguments and then calling getMethod(put, ..) with
Robert every combination.
You could use Class.getMethods to get an array of all methods in a
class, then search for the method that allows this call, by using
isAssignableFrom on the arguments. That's about all I can think of.
This is more efficient than using getMethod since you don't need to
generate all combinations of the method argument types. getMethods
will look at the inheritance tree for you, so you only need to call it
once.
Tom
___
Classpath mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/classpath
RE: finding method efficiently
Tom Tromey writes
Robert == Robert Schuster [EMAIL PROTECTED] writes:
Robert Now when evaluating the XML data I have to search the method put
Robert which accepts the two arguments. Having
Robert only String and JFrame as argument types means that the call to
Robert HashMap.class.getMethod(put, new Class[] { String.class,
Robert JFrame.class });
Robert will fail. My current naive approach to find HashMap.put(Object,
Robert Object) is to generate a long list of a superclasses and
Robert interfaces of all arguments and then calling getMethod(put, ..)
Robert with every combination.
You could use Class.getMethods to get an array of all methods in a
class, then search for the method that allows this call, by using
isAssignableFrom on the arguments. That's about all I can think of.
This is more efficient than using getMethod since you don't need to
generate all combinations of the method argument types. getMethods
will look at the inheritance tree for you, so you only need to call it
once.
But first you have to filter out the public methods, as getMethods will
return them all.
Hmmm. There is a further problem that you have to work out how to do this
such that overload resolution is applied correctly. Basically I can't see
any way to do this other than to reapply the same method resolution logic
that javac would use! Find all applicable methods, then find the most
specific.
For the XML not to carry the parameter type information seems fundamentally
broken. :(
David Holmes
___
Classpath mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/classpath
Re: finding method efficiently
David == David Holmes [EMAIL PROTECTED] writes: David Hmmm. There is a further problem that you have to work out how David to do this such that overload resolution is applied David correctly. Basically I can't see any way to do this other than David to reapply the same method resolution logic that javac would David use! Find all applicable methods, then find the most specific. Yeah, I agree, based on what I read it does seem that way. This algorithm is going through an overhaul as a result of all the new language features, I wonder if that will propagate to XMLDecoder. Tom ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
RE: finding method efficiently
Tom Tromey writes: Yeah, I agree, based on what I read it does seem that way. This algorithm is going through an overhaul as a result of all the new language features, I wonder if that will propagate to XMLDecoder. At least the algorithm has been overhauled such that the new features do not impact if they are not used. The algorithm has been broken into phases such that phase 1 performs the old algorithm, then subsequent phases repeat the old algorithm after applying boxing/unboxing, varargs and generics etc. Regardless this is not something I would want to hand code using the reflection API as Robert must do. David ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
Re: finding method efficiently
David Holmes wrote: Regardless this is not something I would want to hand code using the reflection API as Robert must do. I have come across this same challenge several times now, i.e., having to write code that implements the Java best match semantics for method invocation using reflection. Usually I end up doing something that works in all the 'easy' cases and punt on the rest. For an almost-example, look at Classpath's java.lang.Class.internalGetMethod(). So it would be nice if we could write this algorithm once and for all and make it public somewhere :-) -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
