commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Morgan Delagrange <mdela...@yahoo.com>
Subject moving reflection classes out of beanutils (was: Re: [beanutils] ConstructorUtils in beanutils: a bad idea)
Date Thu, 05 Dec 2002 19:20:20 GMT
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.  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.

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.

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


Mime
View raw message