[
https://issues.apache.org/jira/browse/LANG-416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12579850#action_12579850
]
Matt Benson commented on LANG-416:
----------------------------------
@Hen: I was a little confused by "as they're there there's no point
duplicating" (Nice use of three consecutive homophones, btw). Do I interpret
that correctly to say your preference is to preserve the status quo _if_
BeanUtils continues to be relevant enough to warrant ongoing releases?
@Stephen: I assume you mean [clazz]. Even after I found the true
reflection-based code, I never found code that could do the hardest part (IMO)
of what MethodUtils does: implementing compile-time overloaded method
selection at runtime. The story of what happened to [clazz] is certainly one
I'd like to hear. (Why are the core interfaces not represented in the Javadoc?)
I still have a hard time swallowing that any project wanting some help with
Method/Constructor related code should be encumbered by a dependency as focused
(and therefore conceptually, if not actually, "heavy") as BeanUtils in order to
get it. As usual, however, we'll arrive at a consensus by majority
opinion/vote and act accordingly. While we're here, however, I will also point
out the fact that overlap already exists between parts of [beanutils]
MethodUtils and [lang] ClassUtils, in both directions.
> Import MethodUtils and ConstructorUtils from BeanUtils
> ------------------------------------------------------
>
> Key: LANG-416
> URL: https://issues.apache.org/jira/browse/LANG-416
> Project: Commons Lang
> Issue Type: New Feature
> Affects Versions: 2.4
> Reporter: Matt Benson
> Fix For: 3.0
>
>
> Mentioned on the mailing list... After we release 2.4 I'd like to:
> - import ConstructorUtils
> - make CU.getMatchingAccessibleConstructor() public
> - import MethodUtils
> - factor best-match calculation code out of MethodUtils into abstract
> superclass MemberUtils, make ConstructorUtils extend MemberUtils and use the
> same code (be on the lookout for ways to improve best-match calcs; my
> original description was based on javadoc that said the first matching method
> encountered was used, but this comment seems to have been outdated).
> - merge any other duplicate (or near-duplicate) code from CU/MethodU into
> MemberU and remove anything else that doesn't make sense in the context of
> Lang.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
