commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <robertburrelldon...@blueyonder.co.uk>
Subject Re: [beanutils] ConstructorUtils in beanutils: a bad idea
Date Thu, 05 Dec 2002 23:18:14 GMT
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:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message