commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <cmanola...@yahoo.com>
Subject Re: [beanutils] ConstructorUtils in beanutils: a bad idea
Date Thu, 05 Dec 2002 22:49:43 GMT
I'm not sure I understand what is proposed :-)
However I'm strongly -1 on removing ( or deprecating ) public
code in beanutils, or on adding more dependencies.

It works fine and if another package wants to do reflection - that's 
perfectly fine, but that doesn't mean everyone else is required to
stop doing reflection. If duplication is a concern - then just use 
beanutils ( however duplication is explicitely allowed in commons AFAIK).

beanutils is stable, it works well, it had a number of releases that 
are used in at least few jakarta projects ( tomcat for example ). The 
change doesn't add any new feature and doesn't fix any bug. 


Costin




robert burrell donkin 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>


Mime
View raw message