On Saturday, November 2, 2002, at 05:40 AM, Craig R. McClanahan wrote:
On Fri, 1 Nov 2002, robert burrell donkin wrote:
<snip>
some good points strongly made. i think that's helped to clarify some things for me.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.
i'm not sure that the lang API should end up with a default method - just a range of clearly defined ones. components using the library should pick the one which is most appropriate.
from a beanutils and digester perspective, i wouldn't give users the choice - i'd say that compiler equivalence is definitely what's needed. so those components should use the compiler equivalent methods in the API.
one major problem with the current MethodUtil's implementation is that it'
s aims are fuzzy. the aim should have been to find methods exactly as the compiler does. in practice, i suspect that the workarounds for the bugs in reflection implementations may mean that some methods which shouldn't be found, are found. we've also got some methods in there that allow users to rely on the reflection ideosyncracies of whatever JVM they're currently running on. this (with hindsight) was probably a poor idea.
so i'd like a cleaner and clearer API.
if beanutils finds either more or less methods than the compiler would, then IMHO both cases are equally buggy. but this isn't clear in the current API. the current situation allows users quite reasonably to rely on behaviour that should IMHO be buggy (ie replying on beanutils to find methods which wouldn't be found by the compiler).
how does this sound to everyone?
- robert
--
To unsubscribe, e-mail: <mailto:commons-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@;jakarta.apache.org>
