commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <robertdon...@mac.com>
Subject Re: [Reflect] Summary of points and relationship with BeanUtils
Date Tue, 18 Jun 2002 22:13:15 GMT

On Monday, June 17, 2002, at 11:59 PM, Stephen Colebourne wrote:

> Hi,
> The discussion so far has led me to the following:
>
> 1) There are lots of ideas in this area
> 2) BeanUtils are concerned that previously tested code will be forgotten

i'm not concerned that the code will be forgotten. i really couldn't care 
less. it's just that i know how tough it was to get that code debugged. 
personally, i'd be very reluctant to allow any of the components i'm 
involved with to change from the well tested low level introspection code 
in beanutils to new, (relatively) untested code in reflect.

<snip>

> One suggestion has been that reflect is just adding functionality to the
> BeanUtils project. I disagree. BeanUtils mandates the bean naming
> conventions as defined by BeanUtils. This is very specific. Thus my
> intention is to copy MethodUtils to reflect and add/amend it.

-1

this way, madness lies...

at the moment, beanutils cannot depend on reflect since reflect hasn't 
been released. it really is as simple as that. reflect could very easily 
and reasonably depend on beanutils for these low level utilities.

let's face it, neither reflect nor beanutils have a strong claim to the 
code. both should really be concerned with higher level concepts. all the 
arguments rolled out about why the code doesn't belong in beanutils apply 
equally to reflect also. the low level introspection code doesn't fit very 
well in either component but needs to find a home somewhere.

my objections to moving the low level introspection code to reflect are 
purely practical. until reflect is released none of the released 
components can depend on it. therefore, the code has to remain in 
beanutils (at least for the moment).

i don't believe that duplicating the low level utilities is any sort of a 
solution. having only one set of low level introspection utilities is 
something that i think is very important since they are hard to write, 
hard to test and hard to debug.

i really hate to say this but i would have to think seriously about 
vetoing reflect if i thought that it would splinter the introspection code 
base. sorry - but that's how i feel.

i hope that it's still early enough to find some way to work together on 
this issue. that's why i've tried to make the strength of my feelings on 
this issue clear very early.

- 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