You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by robert burrell donkin <ro...@blueyonder.co.uk> on 2002/12/04 19:38:15 UTC
[beanutils] ConstructorUtils in beanutils: a bad idea
hey rodney!
(i've been trying to get in touch for a while.)
i don't really want to have to -1 your addition of ConstructorUtils to
beanutils but i really think that lang is the right place for this class.
are there any good reasons why it needs to be in beanutils?
- robert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [beanutils] ConstructorUtils in beanutils: a bad idea
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Thursday, December 5, 2002, at 10:49 PM, Costin Manolache wrote:
> I'm not sure I understand what is proposed :-)
it's the same old proposal. discussed at length a long time ago. have only
one canonical set of basic reflection code that's easy to maintain and bug
fix.
> However I'm strongly -1 on removing ( or deprecating ) public
> code in beanutils, or on adding more dependencies.
the MethodUtil's public API is deeply flawed. it can't be maintained
effectively since the methods do not have proper contracts.
> 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.
it's an issue for me since i'm not willing to maintain, develop and
support two separate basic reflection code bases. since errors are hard to
track down, it's in everybody's best interests if as many components as
possible shared the same reflection code.
> If duplication is a concern - then just use
> beanutils ( however duplication is explicitely allowed in commons AFAIK).
i've been convinced that beanutils is not the right place for this code.
the argument is that the basic low level reflection code should be able to
be shared by all higher level introspection (beanutils) and components
which use introspection-alternatives without having to depend on their
peers. having to depend on beanutils is a major issue for some projects.
- robert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [beanutils] ConstructorUtils in beanutils: a bad idea
Posted by Costin Manolache <cm...@yahoo.com>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: moving reflection classes out of beanutils (was: Re: [beanutils]
ConstructorUtils in beanutils: a bad idea)
Posted by Rodney Waldhoff <rw...@apache.org>.
On Thu, 5 Dec 2002, robert burrell donkin wrote:
> i only threatened to -1 after trying quite a few times to get rodney to
> discuss his commit.
I'm not interested in starting some sort of flame war on this minor point,
but for the record, I saw exactly two emails on this--one directly to my
apache.org account, which was received on Thanksgiving day, and the other
to commons-dev (cc'ing me as well), to which I responded in about 3 1/2
hours. One is significantly less than "quite a few". If you sent other
notes, I'm afraid I must have missed them.
> moving MethodUtils to lang is a totally different issue.
Currently ConstructorUtils depends upon MethodUtils, so that's not
strictly true. See also my initial note on this topic [1] (or for that
matter the initial CVS commit message to which you responded) which
suggests otherwise
[1] <http://archives.apache.org/eyebrowse/ReadMsg?listName=commons-dev@jakarta.apache.org&msgNo=19855>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [beanutils] moving reflection classes out of beanutils
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Saturday, December 7, 2002, at 06:59 AM, Costin Manolache wrote:
> Craig R. McClanahan wrote:
>
>>> It doesn't quite matter. There are people using it ( digester, other
>>> projects), it was released - we have to live with it. We may learn a
>>> lesson about APIs and use it next time, but as long as it does what it
>>> is
>>> supposed to do and works - you can't remove it.
>
>> I believe that adding a dependency on [lang] or [reflect] would itself be
>> grounds for a 2.x version number for [beanutils], even with no other
>> changes (although there would undoubtedly be some).
>
> I don't know.
>
> this kind of stuff.
>
> If the [reflect] package will have the same features and better API -
> then it may be better to mark beanutils as "stable"/"closed" and
> migrate modeler, digester, etc directly to [reflect]. I don't see why
> would we need a 2.x version.
the plan was to separate out just the reflection utilities leaving
beanutils focused exclusively on introspection. digester (for example)
would still need to use beanutils for introspection but may want to
migrate to the improved reflection utilities.
the critical flaw with the old MethodUtils API is that the method
contracts are not written in a way that makes it clear what are bugs and
what aren't. fixing this will mean changing the method symantics. the
reflection methods will work better but differently. i'd say that's a good
reason for making it version 2.0.
components using beanutils expect that MethodUtils should work to the java
language specification. users who use MethodUtils directly rely on the
method descriptions. they can quite reasonable rely on a feature of the
current code which deviates from the correct behaviour (as far as the
other components are concerned).
the flaw also makes it impossible to create comprehensive test cases.
- robert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [beanutils] moving reflection classes out of beanutils
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Saturday, December 7, 2002, at 09:32 PM, Henri Yandell wrote:
<snip>
> So... we let Robert/Stephen/others finish up with reflect in lang while
> copying across modifications that occur to those areas in beanutils...
unfortunately, the modifications and fixes can't be copied across.
the public API of the MethodUtils in beanutils is not precisely defined
enough to allow this. we need a new API which has precise, testable method
definitions so that it's clear what a bug is.
> then we have big argument then? :)
true
- robert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [beanutils] moving reflection classes out of beanutils
Posted by Henri Yandell <ba...@generationjava.com>.
On Fri, 6 Dec 2002, Costin Manolache wrote:
> Craig R. McClanahan wrote:
>
> I don't know.
>
> this kind of stuff.
>
> If the [reflect] package will have the same features and better API -
> then it may be better to mark beanutils as "stable"/"closed" and
> migrate modeler, digester, etc directly to [reflect]. I don't see why
> would we need a 2.x version.
>
> I don't think we need more than a component for this kind of stuff -
> or at least I would use a single component ( even beanutils ) over
> some reflection that is split in more components. Matter of taste,
> of course - but also complexity, dependencies, spaghetti.
>
Because reflection and beans are different things. Many things will want
to do reflection, but won't have any interest in some form of bean API.
The same holds for BeanUtils' Convertor system. Many things will want to
use this, but have no interest in Beans.
Having to deal with a library which is created with a context of JavaBeans
means that the Convertor and Reflection APIs will be tainted by this
context.
> > It's clear that ConstructorUtils and MethodUtils belong together,
> > wherever they end up. But it seems less clear that a move would mean
> > *deleting* MethodUtils from [beanutils]. It's straightforward to leave
> > the existing APIs available (for backwards compatibility), but as wrappers
> > around calls to the new functionality, probably deprecated but at least
> > kept through a 2.x version lifecycle. That way, the actual functionality
> > is still in one place for easy maintenance/enhancement, we can fix the
> > method names in the new versions, and users of MethodUtils can migrate in
> > a controlled manner, at their own leisure.
>
> My point is that it would be better if the new package would focus
> on doing what it has to do - API, implementation, features.
Yep. And ConstructorUtils/MethodUtils are outside the scope of BeanUtils
in my view, even if the PROPOSAL does provide some mention of
reflection/introspection utilities.
> When it's ready - we can decide if it makes sense to deprecate ( freeze )
> beanutils entirely, implement it as a wrapper for backward compat -
> or keep it if it fits a different niche.
Agreed. It's always better to debate a piece of code when it's sitting and
ready for inclusion in a particular library somewhere, especially with
something like reflection where it's pretty independent of the surrounding
library.
So... we let Robert/Stephen/others finish up with reflect in lang while
copying across modifications that occur to those areas in beanutils...
then we have big argument then? :)
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [beanutils] moving reflection classes out of beanutils
Posted by Costin Manolache <cm...@yahoo.com>.
Craig R. McClanahan wrote:
>> It doesn't quite matter. There are people using it ( digester, other
>> projects), it was released - we have to live with it. We may learn a
>> lesson about APIs and use it next time, but as long as it does what it is
>> supposed to do and works - you can't remove it.
> I believe that adding a dependency on [lang] or [reflect] would itself be
> grounds for a 2.x version number for [beanutils], even with no other
> changes (although there would undoubtedly be some).
I don't know.
this kind of stuff.
If the [reflect] package will have the same features and better API -
then it may be better to mark beanutils as "stable"/"closed" and
migrate modeler, digester, etc directly to [reflect]. I don't see why
would we need a 2.x version.
I don't think we need more than a component for this kind of stuff -
or at least I would use a single component ( even beanutils ) over
some reflection that is split in more components. Matter of taste,
of course - but also complexity, dependencies, spaghetti.
( well, you can do all the introspection witha single class - both ant and
tomcat3 are basically doing that ).
> It's clear that ConstructorUtils and MethodUtils belong together,
> wherever they end up. But it seems less clear that a move would mean
> *deleting* MethodUtils from [beanutils]. It's straightforward to leave
> the existing APIs available (for backwards compatibility), but as wrappers
> around calls to the new functionality, probably deprecated but at least
> kept through a 2.x version lifecycle. That way, the actual functionality
> is still in one place for easy maintenance/enhancement, we can fix the
> method names in the new versions, and users of MethodUtils can migrate in
> a controlled manner, at their own leisure.
My point is that it would be better if the new package would focus
on doing what it has to do - API, implementation, features.
When it's ready - we can decide if it makes sense to deprecate ( freeze )
beanutils entirely, implement it as a wrapper for backward compat -
or keep it if it fits a different niche.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [beanutils] moving reflection classes out of beanutils
Posted by Henri Yandell <ba...@generationjava.com>.
On Fri, 6 Dec 2002, Costin Manolache wrote:
> robert burrell donkin wrote:
>
> > what we have is clear duplication. twice the support and twice the
> > maintenance.
>
> Nobody asks you to support 2 versions. There is nothing wrong with
> duplication ( at least in commons ). You can just maintain and support the
> version you like.
Nothing illegal with 2 versions anyway. If there are duplicate versions,
with no difference in religion between those versions, I would question
the rightness. Especially if it came from the same 'group' of developers.
[Not that I'm stating that Commons is a group of developers in any way]
> >> You're recommending deprecation of a released, public-facing API; Rodney
> >> is not.
> >
> > the (beanutils) MethodUtils API sucks. it was written in haste and now in
> > leisure, i regret that it was written in that way.
>
> It doesn't quite matter. There are people using it ( digester, other
> projects), it was released - we have to live with it. We may learn a lesson
> about APIs and use it next time, but as long as it does what it is supposed
> to do and works - you can't remove it.
So work stops on beanutils and BeanUtilsTNG is created? Why can't it be
removed? I agree that such a removal should imply a large version number
change, ie) BeanUtils 2.0, but what states that Commons libraries have to
follow slow-release deprecation methods?
> This start to look like dependency spaghetti to me, and it does create
> problems.
Yep. Reality is we are going to have N libraries with M dependencies,
where N and M will only get bigger at a rate slightly faster than we can
manage it.
Do we need to have a common plan in Commons? Or do we do our best to
ensure there are no dependencies between projects, ie) each one is
stand-alone and has some kind of copying system for internal function
calls [ie) we copy the jar, change the bytecode to a different package
name, an obfuscated one].
> > my position has always been that i'm not willing to maintain, support or
> > develop two versions of the basic reflection classes. i've also been
> > convinced that beanutils is not the right places for these canonical
> > versions.
>
> Good. Then maintain and support the other version.
While this kind of view is an important one to have in the community [as
detailed in a long thread on jakarta-general or apache-community] in that
it helps to deal with potential forking and potential project-death, it
does seem that the philosophy should be to work together until such a
point as working together is not possible, and then to allow the
community-healing mores to come into play.
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [beanutils] moving reflection classes out of beanutils
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Fri, 6 Dec 2002, Costin Manolache wrote:
> Date: Fri, 06 Dec 2002 07:41:08 -0800
> From: Costin Manolache <cm...@yahoo.com>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: commons-dev@jakarta.apache.org
> Subject: Re: [beanutils] moving reflection classes out of beanutils
>
> robert burrell donkin wrote:
>
> > what we have is clear duplication. twice the support and twice the
> > maintenance.
>
> Nobody asks you to support 2 versions. There is nothing wrong with
> duplication ( at least in commons ). You can just maintain and support the
> version you like.
>
> >> You're recommending deprecation of a released, public-facing API; Rodney
> >> is not.
> >
> > the (beanutils) MethodUtils API sucks. it was written in haste and now in
> > leisure, i regret that it was written in that way.
>
> It doesn't quite matter. There are people using it ( digester, other
> projects), it was released - we have to live with it. We may learn a lesson
> about APIs and use it next time, but as long as it does what it is supposed
> to do and works - you can't remove it.
>
> This start to look like dependency spaghetti to me, and it does create
> problems.
>
I believe that adding a dependency on [lang] or [reflect] would itself be
grounds for a 2.x version number for [beanutils], even with no other
changes (although there would undoubtedly be some).
>
> > my position has always been that i'm not willing to maintain, support or
> > develop two versions of the basic reflection classes. i've also been
> > convinced that beanutils is not the right places for these canonical
> > versions.
>
> Good. Then maintain and support the other version.
>
>
> > in terms of beanutils, i'm not willing to support a release with code in
> > that no one is willing to support. therefore, i'd think about vetoing any
> > contribution if i thought that no one was willing to offer support for
> > that code and maintain it. but you're willing to do that for
> > ConstructorUtils (and MethodUtils if it can't be deprecated), aren't you
> > rodney?
>
> ), it's reasonably clean. If Rodney doesn't want to support it - I can and
> I suppose other people will.
> Beanutils is used in tomcat, and if a bug happens we'll have to fix it
> anyway, and I think we can handle that.
>
It's clear that ConstructorUtils and MethodUtils belong together,
wherever they end up. But it seems less clear that a move would mean
*deleting* MethodUtils from [beanutils]. It's straightforward to leave
the existing APIs available (for backwards compatibility), but as wrappers
around calls to the new functionality, probably deprecated but at least
kept through a 2.x version lifecycle. That way, the actual functionality
is still in one place for easy maintenance/enhancement, we can fix the
method names in the new versions, and users of MethodUtils can migrate in
a controlled manner, at their own leisure.
> Costin
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [beanutils] moving reflection classes out of beanutils
Posted by Costin Manolache <cm...@yahoo.com>.
robert burrell donkin wrote:
> what we have is clear duplication. twice the support and twice the
> maintenance.
Nobody asks you to support 2 versions. There is nothing wrong with
duplication ( at least in commons ). You can just maintain and support the
version you like.
>> You're recommending deprecation of a released, public-facing API; Rodney
>> is not.
>
> the (beanutils) MethodUtils API sucks. it was written in haste and now in
> leisure, i regret that it was written in that way.
It doesn't quite matter. There are people using it ( digester, other
projects), it was released - we have to live with it. We may learn a lesson
about APIs and use it next time, but as long as it does what it is supposed
to do and works - you can't remove it.
This start to look like dependency spaghetti to me, and it does create
problems.
> my position has always been that i'm not willing to maintain, support or
> develop two versions of the basic reflection classes. i've also been
> convinced that beanutils is not the right places for these canonical
> versions.
Good. Then maintain and support the other version.
> in terms of beanutils, i'm not willing to support a release with code in
> that no one is willing to support. therefore, i'd think about vetoing any
> contribution if i thought that no one was willing to offer support for
> that code and maintain it. but you're willing to do that for
> ConstructorUtils (and MethodUtils if it can't be deprecated), aren't you
> rodney?
), it's reasonably clean. If Rodney doesn't want to support it - I can and
I suppose other people will.
Beanutils is used in tomcat, and if a bug happens we'll have to fix it
anyway, and I think we can handle that.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [beanutils] moving reflection classes out of beanutils
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Friday, December 6, 2002, at 06:53 PM, Costin Manolache wrote:
> robert burrell donkin wrote:
>
>> the guidelines have an inbuilt mechanism whereby components may - if they
>> wish - prevent a new existing commons committer joining. that is, they
>> can
>> veto the addition of the committers name to the list of developers for
>> the
>> component.
>
> With a valid technical reason.
>
> Probably it can be done in a majority vote - but I certainly hope we'll
> not reach that point.
+1
- robert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [beanutils] moving reflection classes out of beanutils
Posted by Costin Manolache <cm...@yahoo.com>.
robert burrell donkin wrote:
>
> the guidelines have an inbuilt mechanism whereby components may - if they
> wish - prevent a new existing commons committer joining. that is, they can
> veto the addition of the committers name to the list of developers for the
> component.
With a valid technical reason.
Probably it can be done in a majority vote - but I certainly hope we'll
not reach that point.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [beanutils] moving reflection classes out of beanutils
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Friday, December 6, 2002, at 04:27 PM, Rodney Waldhoff wrote:
<snip>
> And I'm convinced that lang isn't the right place either. Let's split the
> difference and propose commons-reflect or commons-reflection or whatever,
> and end this thread.
+1 but i don't have the energy to force this through.
it's very frustrating for me.
i've been working for some time on creating a solid MethodUtils with a
good API and a comprehensive set of unit tests. this version is taking
shape in lang.
i'd also like to see a new bug fix beanutils release very soon which is
why i switched to fixing beanutils bugs.
- robert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [beanutils] moving reflection classes out of beanutils
Posted by Morgan Delagrange <md...@yahoo.com>.
--- robert burrell donkin
<ro...@blueyonder.co.uk> wrote:
<snip/>
>
> the guidelines have an inbuilt mechanism whereby
> components may - if they
> wish - prevent a new existing commons committer
> joining. that is, they can
> veto the addition of the committers name to the list
> of developers for the
> component.
>
> - robert
>
Are you sure about that? I don't see that anywhere:
http://jakarta.apache.org/commons/charter.html
AFAIK there are no restrictions on existing committers
working on other existing components. If you're
implying that committers can exercise their veto on
the actual commit of a new developer's name to the
STATUS file, that's not so. Commits can only be
vetoed for valid technical reasons. I can't imagine
the technical justification for "you can't work on my
component".
Adding your name to the STATUS file is a courtesy.
Nobody should be ostracized for not doing it:
Version 1.8:
http://cvs.apache.org/viewcvs/jakarta-commons/beanutils/STATUS.html#rev1.8
Version 1.6:
http://cvs.apache.org/viewcvs/jakarta-commons/beanutils/src/java/org/apache/commons/beanutils/MethodUtils.java#rev1.6
- Morgan
=====
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [beanutils] moving reflection classes out of beanutils
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Friday, December 6, 2002, at 04:27 PM, Rodney Waldhoff wrote:
> On Thu, 5 Dec 2002, robert burrell donkin wrote:
>
>> On Thursday, December 5, 2002, at 08:39 PM, Morgan Delagrange wrote:
>>> --- robert burrell donkin
>>> <ro...@blueyonder.co.uk> wrote:
>>
>> <snip>
>>
>>>> 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.
>>
>> asking is a matter of politeness and means that his participation is less
>> likely to be vetoed.
>>
>> a committer has responsibilities as well as rights. if i thought that a
>> committer was just dumping code into a component and had no intention of
>> maintaining that code, i wouldn't hesitate to veto.
>>
>
> I really offended by this comment, Robert. The commit you refer to was
> not only well within my rights *and* responsibilities, clearly following
> both the spirit and letter of the asf, jakarta, and jakarta-commons
> guidelines, but also well within the bounds of politeness and courtesy.
> This commit was small (one class, about ~300 lines counting comments and
> blanks), unobtrusive (no new dependencies, configuration, extra processing
> or memory use was introduced), fully backwards compatible, and well within
> the scope of the project. The "commit then review" protocol is clearly
> appropriate (and polite) in this circumstance. If I need your explicit
> approval before making a small, unobtrusive, fully backwards compatible
> and in scope commit, then Guideline #15 (Each committer has karma to all
> the packages) is meaningless.
i'm sorry you feel this way rodney. i'd thought i'd made it clear that
these criticisms don't apply to you.
i was trying (and failing) to speak in general terms.
the guidelines have an inbuilt mechanism whereby components may - if they
wish - prevent a new existing commons committer joining. that is, they can
veto the addition of the committers name to the list of developers for the
component.
- robert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [beanutils] moving reflection classes out of beanutils
Posted by Rodney Waldhoff <rw...@apache.org>.
On Thu, 5 Dec 2002, robert burrell donkin wrote:
> On Thursday, December 5, 2002, at 08:39 PM, Morgan Delagrange wrote:
> > --- robert burrell donkin
> > <ro...@blueyonder.co.uk> wrote:
>
> <snip>
>
> >> 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.
>
> asking is a matter of politeness and means that his participation is less
> likely to be vetoed.
>
> a committer has responsibilities as well as rights. if i thought that a
> committer was just dumping code into a component and had no intention of
> maintaining that code, i wouldn't hesitate to veto.
>
I really offended by this comment, Robert. The commit you refer to was
not only well within my rights *and* responsibilities, clearly following
both the spirit and letter of the asf, jakarta, and jakarta-commons
guidelines, but also well within the bounds of politeness and courtesy.
This commit was small (one class, about ~300 lines counting comments and
blanks), unobtrusive (no new dependencies, configuration, extra processing
or memory use was introduced), fully backwards compatible, and well within
the scope of the project. The "commit then review" protocol is clearly
appropriate (and polite) in this circumstance. If I need your explicit
approval before making a small, unobtrusive, fully backwards compatible
and in scope commit, then Guideline #15 (Each committer has karma to all
the packages) is meaningless.
Moreover, when making a commit that fails to meet any one of these
criteria, I've very consistently brought this to the attention of the
development community, before, immediately after, or both before and after
making the commit, no matter how long I've been working on or with the
project, or for that matter whether or not I've been to primary developer
working on it, as you can see in [1] and [2] and [3] and [4] and [5] and
[6] and [7] and others.
I'm not disputing your right to question (i.e., review) this commit, but
don't suggest that it was inappropriate or impolite or somehow makes me a
bad citizen.
[1] <http://archives.apache.org/eyebrowse/ReadMsg?listName=commons-dev@jakarta.apache.org&msgId=76126>
[2] <http://archives.apache.org/eyebrowse/ReadMsg?listName=commons-dev@jakarta.apache.org&msgId=78100>
[3] <http://archives.apache.org/eyebrowse/ReadMsg?listName=commons-dev@jakarta.apache.org&msgId=344668>
[4] <http://archives.apache.org/eyebrowse/ReadMsg?listName=commons-dev@jakarta.apache.org&msgId=513101>
[5] <http://archives.apache.org/eyebrowse/ReadMsg?listName=commons-dev@jakarta.apache.org&msgId=525232>
[6] <http://archives.apache.org/eyebrowse/ReadMsg?listName=commons-dev@jakarta.apache.org&msgId=559250>
[7] <http://archives.apache.org/eyebrowse/ReadMsg?listName=commons-dev@jakarta.apache.org&msgId=564947>
> the consensus which emerged from the lengthy discussions on this issue
> supports me, though.
That's not "consensus" in the standard meaning--there are those that
disagree with this approach. It's certainly not "consensus" in any formal
ASF sense, since there was no actual [VOTE] on the issue, so claiming it
as a matter of policy is questionable in my eyes.
> in terms of beanutils, i'm not willing to support a release with code in
> that no one is willing to support. therefore, i'd think about vetoing
> any contribution if i thought that no one was willing to offer support
> for that code and maintain it. but you're willing to do that for
> ConstructorUtils (and MethodUtils if it can't be deprecated), aren't you
> rodney?
I'm trying real hard not to feel condescended to here Robert. I'm
willing to fulfill my responsiblities as an Apache committer and feel
I've got a pretty strong record of doing so.
(and from a different thread)
Costin> If duplication is a concern - then just use
Costin> beanutils ( however duplication is explicitely
Costin> allowed in commons AFAIK).
Robert> i've been convinced that beanutils is
Robert> not the right place for this code.
And I'm convinced that lang isn't the right place either. Let's split the
difference and propose commons-reflect or commons-reflection or whatever,
and end this thread.
- R.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [beanutils] moving reflection classes out of beanutils
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Thursday, December 5, 2002, at 08:39 PM, Morgan Delagrange wrote:
> --- robert burrell donkin
> <ro...@blueyonder.co.uk> wrote:
<snip>
>> 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.
asking is a matter of politeness and means that his participation is less
likely to be vetoed.
a committer has responsibilities as well as rights. if i thought that a
committer was just dumping code into a component and had no intention of
maintaining that code, i wouldn't hesitate to veto.
rodney has convinced me that this isn't so in this case.
> 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.
what we have is clear duplication. twice the support and twice the
maintenance.
if rodney couldn't supply a good reason why we should support and maintain
two versions of the same code, then i wouldn't hesitate to veto the
contribution on those grounds. but now he's offered one, we can (hopefully)
make progress.
> Precedent supports Rodney, so the onus is largely on you.
the consensus which emerged from the lengthy discussions on this issue
supports me, though.
> You're recommending deprecation of a released, public-facing API; Rodney
> is not.
the (beanutils) MethodUtils API sucks. it was written in haste and now in
leisure, i regret that it was written in that way.
<snip>
>> 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.
i haven't vetoed anything. i threatened to veto unless rodney offered up
an explanation. it's not possible to have a discussion unless you have
someone to discuss with.
>> 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.
versions of both classes already exist in lang.
adding ConstructorUtils to beanutils now means that both have to be
deprecated or neither.
>> 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?
i haven't vetoed it, have i?
my position has always been that i'm not willing to maintain, support or
develop two versions of the basic reflection classes. i've also been
convinced that beanutils is not the right places for these canonical
versions.
in terms of beanutils, i'm not willing to support a release with code in
that no one is willing to support. therefore, i'd think about vetoing any
contribution if i thought that no one was willing to offer support for
that code and maintain it. but you're willing to do that for
ConstructorUtils (and MethodUtils if it can't be deprecated), aren't you
rodney?
- robert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [beanutils] moving reflection classes out of beanutils (was: Re: [beanutils] ConstructorUtils in beanutils: a bad idea)
Posted by Morgan Delagrange <md...@yahoo.com>.
--- robert burrell donkin
<ro...@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
> > <ro...@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:
> >>
> <ma...@jakarta.apache.org>
> >> For additional commands, e-mail:
> >> <ma...@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:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: moving reflection classes out of beanutils (was: Re: [beanutils] ConstructorUtils in beanutils: a bad idea)
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
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
> <ro...@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:
>> <ma...@jakarta.apache.org>
>> For additional commands, e-mail:
>> <ma...@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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
moving reflection classes out of beanutils (was: Re: [beanutils] ConstructorUtils in beanutils: a bad idea)
Posted by Morgan Delagrange <md...@yahoo.com>.
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
<ro...@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:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [beanutils] ConstructorUtils in beanutils: a bad idea
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [beanutils] ConstructorUtils in beanutils: a bad idea
Posted by Rodney Waldhoff <rw...@apache.org>.
I did recall seeing some threads around lang/beanutils/reflection/clazz,
indeed before I wrote ConstructorUtils I checked those places for the
functionality I was looking for. Lang's ConstructorUtil class wasn't quite
it, and the last commit message reads "[...] (not all working)", which
wasn't exactly confidence inspiring. Neither reflection nor reflect seem
to exist anywhere. While the clazz proposal seems about right, frankly I'm
not really sure what clazz is about or what state it is in. Beanutils'
MethodUtils was exactly what I wanted, except I wanted Constructors
instead of Methods, so that's where it went.
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.
I feel pretty strongly that putting reflection utilities is commons-lang
represents a change in scope from lang's original proposal [2] and is in
violation of the spirit of the first three guidelines listed in the
jakarta-commons charter [3] as well as a number of common OO design
principles (the Common Reuse Principle, the Reuse/Release Equivalence
Principle, the Common Closure Principle etc., see, for example, [4] or
[5]).
Concretely, consider adding reflection (or for that matter predicate)
utilities to lang in light of
(a) the Common Reuse Principle--The classes in a package are reused
together. If you reuse of of the classes in a package, you reuse them all
and
(b) the Reuse/Release Equivalency Principle--The granule of reuse is the
same as the granule of release.
If someone is using MethodUtils, the probablity of also using
ConstructorUtils (and vice versa) is fairly high (relative to an arbitrary
class). Hence these two should likely go into the same commons package
(read component).
In constrast, if someone is using MethodUtils, the probablity of me also
wanting to use, say, NumberRange or Enum, is not signficantly higher that
a user of most other classes (say, a user of commons-logging or
commons-collections). Hence these two should likely not go into the same
commons package.
(I'd argue that if you're using MethodUtils/ConstructorUtils, the odds of
wanting to use something like Converter or BeanUtils is higher than
average, but I'd agree that's not as strong a "common [re]use" coupling as
the "core" reflection utilties.)
The "reflect" package idea seemed generally well received in the messages
I poked through in the archives [6], I'm not sure why we didn't/aren't
going down that path (maybe I didn't poke hard enough?). Is "clazz" what
became of "reflect"? (It seems to be from the proposal doc, but the
current implementation seems to have a different focus.)
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.
[1] <http://archives.apache.org/eyebrowse/ReadMsg?listName=commons-dev@jakarta.apache.org&msgId=519705>
[2] <http://cvs.apache.org/viewcvs.cgi/*checkout*/jakarta-commons/lang/PROPOSAL.html?rev=HEAD&content-type=text/html>
[3] <http://jakarta.apache.org/commons/charter.html>
[4] <http://www.objectmentor.com/resources/articles/granularity.pdf>
[5] <http://www.google.com/search?q=principles+of+object+oriented+design>
[6] <http://archives.apache.org/eyebrowse/SearchList?listId=&listName=commons-dev@jakarta.apache.org&searchText=reflect&defaultField=subject&Search=Search>
- Rod
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [beanutils] ConstructorUtils in beanutils: a bad idea
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Wed, 4 Dec 2002, Rodney Waldhoff wrote:
> Date: Wed, 4 Dec 2002 13:54:59 -0800 (PST)
> From: Rodney Waldhoff <rw...@apache.org>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> Subject: Re: [beanutils] ConstructorUtils in beanutils: a bad idea
>
> On Wed, 4 Dec 2002, robert burrell donkin wrote:
>
> >
> > i really think that lang is the right place for this [ConstructorUtils].
> > are there any good reasons why it needs to be in beanutils?
> >
>
> I disagree that ConstructorUtils belongs in lang, or more accurately, I
> believe it is a better fit for beanutils.
>
Rodney,
You might have missed some earlier conversations on this general topic.
The conclusion was that, ultimately, the MethodUtils class would migrate
from [beanutils] to either [lang] or [reflect], and be complemented there
by ConstructorUtils and other similar goodies. The reasoning was that
MethodUtils was generally useful for calling methods other than beans, and
there were some very tricky workarounds for JDK introspector bugs -- we
wanted people who needed to reflectively call methods not to have to go
through the same pain.
Ultimately, it looks like the decision was to move MethodUtils to [lang],
and ultimately [beanutils] could deprecate our copy and declare a
dependency. If that's still the plan (which I guess it is), we should put
ConstructorUtils where it will end up, rather than here and moving it.
> Why?
>
> 1) ConstructorUtils is directly parallel to the existing MethodUtils,
> /s/Method/Constructor:
>
> class ConsructorUtils {
> Object invokeConstructor(Class klass, Object arg);
> Object invokeConstructor(Class klass, Object[] args);
> Object invokeConstructor(Class klass, Object[] args, Class[] parameterTypes);
> Object invokeExactConstructor(Class klass, Object arg);
> Object invokeExactConstructor(Class klass, Object[] args);
> Object invokeExactConstructor(Class klass, Object[] args, Class[] parameterTypes);
> // [...]
> }
>
> class MethodUtils {
> Object invokeMethod(Object object, String methodName, Object arg);
> Object invokeMethod(Object object, String methodName, Object[] args);
> Object invokeMethod(Object object, String methodName, Object[] args, Class[] parameterTypes);
> Object invokeExactMethod(Object object, String methodName, Object arg);
> Object invokeExactMethod(Object object, String methodName, Object[] args);
> Object invokeExactMethod(Object object, String methodName, Object[] args, Class[] parameterTypes);
> // [...]
> }
>
> 2) ConstructorUtils fits within the scope of orignal beanutils proposal
> rather cleanly:
>
> "The Java language provides Reflection and Introspection APIs (see the
> java.lang.reflect and java.beans packages in the JDK Javadocs). However,
> these APIs can be quite complex to understand and utilize. The BeanUtils
> component provides easy-to-use wrappers around these capabilities."
> <http://cvs.apache.org/viewcvs.cgi/*checkout*/jakarta-commons/beanutils/PROPOSAL.html?rev=HEAD&content-type=text/html>
>
> And is likely to be useful for the use cases enumerated withing that
> proposal:
>
> "Example use cases include:
> * Building scripting languages that interact with the Java object model [...]
> * Building template language processors for web presentation and similar uses [...]
> * Building custom tag libraries for JSP and XSP environments [...]
> * Consuming XML-based configuration resources [...]"
> <http://cvs.apache.org/viewcvs.cgi/*checkout*/jakarta-commons/beanutils/PROPOSAL.html?rev=HEAD&content-type=text/html>
>
> The same isn't true for lang:
>
> "This proposal is to create a package of Java utility classes for the
> classes that are in java.lang's hierarchy, or are considered to be so
> standard as to justify existence in java.lang. The Lang Package also
> applies to primitives and arrays."
> <http://cvs.apache.org/viewcvs.cgi/*checkout*/jakarta-commons/lang/PROPOSAL.html?rev=HEAD&content-type=text/html>
>
There's no doubt that ConstructorUtils would be useful -- and there's even
an enhancement request against beanutils to add it. Given the advent of
[lang], though, I think it would make sense for [beanutils] to refine its
focus a little on things that are specifically JavaBeans related (the
property accessor stuff today, maybe some frameworks for event listeners
and such later?).
>
> 3) More importantly, beanutils forms a cohesive set of reflection-oriented
> and reflection-based classes. The average user of an arbitrary class in
> beanutils is significantly more likely to have use for ConstructorUtils
> that the average user of lang. Similiarly, the average user of
> ConstructorUtils is significantly more likely to have use for other
> classes in beanutils than other classes in lang. This is in keeping with
> points 1, 2, and 3 of the jakarta-commons charter
> <http://jakarta.apache.org/commons/charter.html>
>
>
> I think one could argue for some sort of commons-reflection package that
> contains pieces of beanutils, lang, clazz, etc. (although I'm not sure how
> different that would be from the existing beanutils package), but for the
> time being I'm pretty sure that's closer to beanutils than to lang.
>
There's circa 100 messages in the COMMONS-DEV archives on just this topic
if you'd care to read them :-).
> - Rod
>
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [beanutils] ConstructorUtils in beanutils: a bad idea
Posted by Rodney Waldhoff <rw...@apache.org>.
On Wed, 4 Dec 2002, robert burrell donkin wrote:
>
> i really think that lang is the right place for this [ConstructorUtils].
> are there any good reasons why it needs to be in beanutils?
>
I disagree that ConstructorUtils belongs in lang, or more accurately, I
believe it is a better fit for beanutils.
Why?
1) ConstructorUtils is directly parallel to the existing MethodUtils,
/s/Method/Constructor:
class ConsructorUtils {
Object invokeConstructor(Class klass, Object arg);
Object invokeConstructor(Class klass, Object[] args);
Object invokeConstructor(Class klass, Object[] args, Class[] parameterTypes);
Object invokeExactConstructor(Class klass, Object arg);
Object invokeExactConstructor(Class klass, Object[] args);
Object invokeExactConstructor(Class klass, Object[] args, Class[] parameterTypes);
// [...]
}
class MethodUtils {
Object invokeMethod(Object object, String methodName, Object arg);
Object invokeMethod(Object object, String methodName, Object[] args);
Object invokeMethod(Object object, String methodName, Object[] args, Class[] parameterTypes);
Object invokeExactMethod(Object object, String methodName, Object arg);
Object invokeExactMethod(Object object, String methodName, Object[] args);
Object invokeExactMethod(Object object, String methodName, Object[] args, Class[] parameterTypes);
// [...]
}
2) ConstructorUtils fits within the scope of orignal beanutils proposal
rather cleanly:
"The Java language provides Reflection and Introspection APIs (see the
java.lang.reflect and java.beans packages in the JDK Javadocs). However,
these APIs can be quite complex to understand and utilize. The BeanUtils
component provides easy-to-use wrappers around these capabilities."
<http://cvs.apache.org/viewcvs.cgi/*checkout*/jakarta-commons/beanutils/PROPOSAL.html?rev=HEAD&content-type=text/html>
And is likely to be useful for the use cases enumerated withing that
proposal:
"Example use cases include:
* Building scripting languages that interact with the Java object model [...]
* Building template language processors for web presentation and similar uses [...]
* Building custom tag libraries for JSP and XSP environments [...]
* Consuming XML-based configuration resources [...]"
<http://cvs.apache.org/viewcvs.cgi/*checkout*/jakarta-commons/beanutils/PROPOSAL.html?rev=HEAD&content-type=text/html>
The same isn't true for lang:
"This proposal is to create a package of Java utility classes for the
classes that are in java.lang's hierarchy, or are considered to be so
standard as to justify existence in java.lang. The Lang Package also
applies to primitives and arrays."
<http://cvs.apache.org/viewcvs.cgi/*checkout*/jakarta-commons/lang/PROPOSAL.html?rev=HEAD&content-type=text/html>
3) More importantly, beanutils forms a cohesive set of reflection-oriented
and reflection-based classes. The average user of an arbitrary class in
beanutils is significantly more likely to have use for ConstructorUtils
that the average user of lang. Similiarly, the average user of
ConstructorUtils is significantly more likely to have use for other
classes in beanutils than other classes in lang. This is in keeping with
points 1, 2, and 3 of the jakarta-commons charter
<http://jakarta.apache.org/commons/charter.html>
I think one could argue for some sort of commons-reflection package that
contains pieces of beanutils, lang, clazz, etc. (although I'm not sure how
different that would be from the existing beanutils package), but for the
time being I'm pretty sure that's closer to beanutils than to lang.
- Rod
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>