commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rodney Waldhoff <rwaldh...@apache.org>
Subject Re: [beanutils] ConstructorUtils in beanutils: a bad idea
Date Thu, 05 Dec 2002 15:25:58 GMT
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:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message