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