Re: moving reflection classes out of beanutils (was: Re: [beanutils] ConstructorUtils in beanutils: a bad idea)

[robert burrell donkin]

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
<[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>

=====
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:[EMAIL PROTECTED].
org>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED].
org>

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>