commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject Re: [lang] MethodUtils
Date Sat, 02 Nov 2002 05:40:14 GMT


On Fri, 1 Nov 2002, robert burrell donkin wrote:

> Date: Fri, 1 Nov 2002 18:36:42 +0000
> From: robert burrell donkin <robertburrelldonkin@blueyonder.co.uk>
> Reply-To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
> To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
> Subject: Re: [lang] MethodUtils
>
>
> On Friday, November 1, 2002, at 08:59 AM, Stephen Colebourne wrote:
>
> > From: "robert burrell donkin" <robertburrelldonkin@blueyonder.co.uk>
> >> i've taken a quick look and you've made quite a few changes. any pointers
> >> you'd like to give me about these changes?
> >
> > I wanted to ensure that the API allowed a choice between the four options
> > I
> > could find:
> > Match on specified class only   vs  Match on class and superclasses
> > Match on public methods/fields  vs  Match on any field made accessible via
> > setAccessible
>
> (presumably, 'Match on class and superclasses' includes superinterfaces)
>
> but that sounds like the right way to write the API. one of the weaknesses
> of MethodUtil's is that the API grew rather than being designed.
>

I have a very strong piece of advice for the [lang] developers (which,
among other things, will be translated into a -1 on any attempt to convert
[beanutils] to depend on a [lang] implementation that doesn't correspond
to the expectations outlined below).

If the *default* method resolution for picking the correct method is
different from the default resolution that the Java compiler does for
figuring out which method to call for hard-coded method references, I
would suggest that that the resolution algorithm is totally broken and
should be rejected out of hand.  There is no reason to expect users of
[lang] to expect anything different from this.

It doesn't matter any more if it makes sense or not -- this is the Java
world as it really exists.  Deal with it, or plan on being ignored.

If the available non-default algorithms work on some more "sane" or
"rational" algorithms (from our point of view as library developers), that
is fine -- as long as the user has to *deliberatey* choose to be different
from what the normal expectations would be.

Craig McClanahan



--
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