On Fri, 1 Nov 2002, robert burrell donkin wrote:
> Date: Fri, 1 Nov 2002 18:36:42 +0000 > From: robert burrell donkin <[EMAIL PROTECTED]> > Reply-To: Jakarta Commons Developers List <[EMAIL PROTECTED]> > To: Jakarta Commons Developers List <[EMAIL PROTECTED]> > Subject: Re: [lang] MethodUtils > > > On Friday, November 1, 2002, at 08:59 AM, Stephen Colebourne wrote: > > > From: "robert burrell donkin" <[EMAIL PROTECTED]> > >> 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>
