commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@btopenworld.com>
Subject Re: [lang] MethodUtils API: invokeMethod, invokeExactMethod
Date Sat, 02 Nov 2002 13:53:43 GMT
In the classes I laid out I did:

getMethod()
looks in class and superclasses, for accessible method, follow JLS

getMethodExact()
looks in class only, for accessible method, follow JLS

getMethod(breakscope=true)
looks in class and superclasses, for any method making accessible using
setAccessible

getMethodExact(breakscope=true)
looks in class only, for any method making accessible using setAccessible

FieldUtils and ConstructorUtils are defined with exactly the same methods.

The invoke methods (get/set in FieldUtils) then work with similar method
names
 invokeMethod()
 invokeMethodExact()
 invokeMethod(breakscope=true)
 invokeMethodExact(breakscope=true)

I want to keep the same naming pattern accross the three classes, and
although I'm not wedded to these precice names, they do seem to work quite
well.

The extra factor in Methods as opposed to Fields (at least how I coded it)
is the lookup of superclasses when considering parameters to the method. One
possible solution would be to return a list of matches if multiple are
found, in order of best match to worst as defined by the JLS. Don't know if
this is useful though.

Stephen


From: "robert burrell donkin" <robertburrelldonkin@blueyonder.co.uk>
> invokeMethod, invokeExactMethod are poorly defined. the java doc comments
> are very loose about their expected behaviour.
>
> i think that methods should be replaced by a single series of methods that
> work as if it were they were compiled ie. use the rules in the JLS.
>
> for example invoke('method', invokee, parameter) should work the same as
> "invokee.method(parameter)" would work when compiled.
>
> this gives a clean, clear target to shoot at. they'll be based on the
> algorithm in invokeExactMethod since this contains workarounds for many
> JVM problems.
>
> comments?
>
> plus any opinions on names?
>
> - robert
>
>
> --
> To unsubscribe, e-mail:
<mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:commons-dev-help@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message