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?[EMAIL PROTECTED]&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=&[EMAIL PROTECTED]&searchText=reflect&defaultField=subject&Search=Search> - Rod -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
