commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <robertburrelldon...@blueyonder.co.uk>
Subject Re: moving reflection classes out of beanutils (was: Re: [beanutils] ConstructorUtils in beanutils: a bad idea)
Date Thu, 05 Dec 2002 20:20:52 GMT
On Thursday, December 5, 2002, at 07:20 PM, Morgan Delagrange wrote:

> So it seems like the point is not "ConstructorUtils in
> beanutils: a bad idea", but rather "Reflection classes
> in beanutils: a bad idea".   It's inappropriate to -1
> adding ConstructorUtils to beanutils on the basis of
> scope, since that is where such classes currently
> belong.

i only threatened to -1 after trying quite a few times to get rodney to 
discuss his commit.

rodney hasn't been a regular contributor to beanutils either in terms of 
code or on the mailing lists. if he couldn't even be bothered to ask 
before making himself a committer or to reply to questions afterwards, 
then it would have been very reasonable to veto his contribution since he 
was asking other committers to support code they were unhappy with. 
luckily, this has turned out not to be the case.

> If you want to move reflection code out of
> beanutils, let's do it all at once with a proper
> discussion and vote, not piecemeal via guerilla
> vetoes.

FWIW we've had lots and lots and lots of discussions on this issue.

a veto is a way to force a discussion and vote on whether ConstructorUtils 
belongs in beanutils. we're already having a discussion. maybe someone 
will propose a vote later. so, it using the veto shouldn't be necessary.

> Personally, beanutils seems like a logical home for
> both of these classes, and I haven't seen the
> convincing argument for moving them.  So I'm -1 on
> moving them at this time.

moving MethodUtils to lang is a totally different issue.

the previous discussions came to a consensus about the right sequence for 
events. right now, the reflect code in lang is still young. the API's need 
fixing and comprehensive test cases created for them. only then will a 
vote be called to deprecate MethodUtils and make beanutils depend on lang.

- robert

> - Morgan
>
> --- robert burrell donkin
> <robertburrelldonkin@blueyonder.co.uk> wrote:
>> On Thursday, December 5, 2002, at 03:25 PM, Rodney
>> Waldhoff wrote:
>>
>> <snip>
>>
>>> Looking through the archives, I now see the thread
>> named
>>> "[beanutils][lang][PROPOSAL] deprecated beanutils
>> version of MethodUtils"
>>> [1] which apparently should have been flagged
>> "[VOTE]", if that was
>>> intended to be a binding vote.
>>
>> no, that thread wasn't binding. that's one reason
>> why i wanted to try to
>> engage you in debate rather than just -1'ing the
>> commit straight away :)
>>
>>> I'd be OK with leaving beanutils as the repository
>> for reflection oriented
>>> stuff.  In light of this thread, I think I'd
>> prefer to create true
>>> reflection oriented commons component.  I'm
>> strongly opposed to moving a
>>> bunch of stuff into lang because it seems somehow
>> central or widely
>>> applicable.  I'd rather see a bunch of focused
>> modules with well defined
>>> scope (however tiny) than a grand utilties
>> framework, and my reading of
>>> the commons charter says it agrees with me.
>>
>> though i agree about your point in general, the
>> reflection code fits
>> perfectly into lang's spec. they are utility classes
>> for package java.lang.
>> reflect.
>>
>> AFAIK class and reflect(ion?) were intended to be
>> introspection-alternatives. they need to rely on
>> solid, low level
>> reflection utilities.
>>
>> - robert
>>
>>
>> --
>> To unsubscribe, e-mail:
>> <mailto:commons-dev-unsubscribe@jakarta.apache.org>
>> For additional commands, e-mail:
>> <mailto:commons-dev-help@jakarta.apache.org>
>>
>
>
> =====
> Morgan Delagrange
> http://jakarta.apache.org/taglibs
> http://jakarta.apache.org/commons
> http://axion.tigris.org
> http://jakarta.apache.org/watchdog
>
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> http://mailplus.yahoo.com
>
> --
> To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.
> org>
> For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.
> org>
>


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message