On Saturday, November 2, 2002, at 01:41 PM, Stephen Colebourne wrote: <snip>
sounds good to me. we'd need to think clearly on the definition of those ignoring scope and get that fixed before we release. but, there's no reason why we'd need to wait until those were finished before releasing implementations for those following the JLS rules.my main issue with the current MethodUtils API is that it not precise inThe comments in [lang] MethodUtils etc. should be tightened. We offer the
it's definition of expected behaviour. the API does not say 'this methods
finds conforms to the JLS spec'. since these methods can be called
directly (rather than just as part of beanutils or digester where the
required behaviour is clear), this lack precision means that people may
rely on these features. therefore changing the algorithm might break their
code.
equivalent of:
getMethod() accessible
getDeclaredMethod() accessible
getMethod() ignoring scope
getDeclaredMethod() ignoring scope
The first two should follow the JLS spec. The last two we get to define what
happens.
since we're most likely going to end up with a series of methods, any ideas about naming conventions?
one alternative to actually including them all in the same class might be split into two classes (possibly sharing common code). we might have PublicMethodUtils for those following the JLS rules and another class for those with looser scope (i can't think of a good name for that class right now).
- robert
--
To unsubscribe, e-mail: <mailto:commons-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@;jakarta.apache.org>
