commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matt Benson (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LANG-416) Import MethodUtils and ConstructorUtils from BeanUtils
Date Tue, 18 Mar 2008 21:33:29 GMT

    [ https://issues.apache.org/jira/browse/LANG-416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12580101#action_12580101
] 

Matt Benson commented on LANG-416:
----------------------------------

Thanks for your candor, Niall.  I am very enthusiastic that Morph has the capacity to be split
into the right components to be a nice next-gen for BeanUtils.  We'll see.  As for [reflect],
it doesn't show up on the dormant nor sandbox sections of the site, so I had missed it originally,
thanks for the pointer.  Looks small, and somewhat telling that it contains a CommonsLang
class, which "Avoids dependency on Commons Lang by copying code to this class."  I understand
the motivation here, but is [reflect] simply too damned small?  :)  Is it possible Commons
Lang (Reflect) could be a subset jar produced by [lang]?  Or could svn externals create [reflect]
from [lang]'s code without ongoing synchronization?  I'm going to keep going down the road
I've been going down for now, and we can then retire the discussion of [reflect] vs. [lang]
vs. [door #3] to the dev list before making any permanent decisions wrt Lang 2.5/3.0.  How's
that?

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


Mime
View raw message