commons-dev mailing list archives

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

--- robert burrell donkin
<robertburrelldonkin@blueyonder.co.uk> wrote:
> 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.

The only email I saw, Rodney responded to in a timely
fashion.

> 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

He's not required to ask, only to indicate his
participation.  Are his contributions less valid
because they are recent?  You don't seem to be
objecting to the quality of the code either, only to
its location based on your opinion of what should or
shouldn't be in beanutils.  Precedent supports Rodney,
so the onus is largely on you.  You're recommending
deprecation of a released, public-facing API; Rodney
is not.

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

I know, I've followed some of the discussion.

> a veto is a way to force a discussion and vote on
> whether ConstructorUtils 
> belongs in beanutils. 

A discussion, leading to a vote, on whether or not to
support reflection in the beanutils package is also a
way to force the issue.  But votes are more
constructive than vetoes.

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

I disagree, MethodUtils and ConstructorUtils are
linked.  Shuffling them around independently is
pointless.

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

So until we actually decide to deprecate MethodUtils,
Rodney's commit is valid, correct?

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


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