Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Message-ID: <00b601c21726$a12be600$dd2d29d9@oemcomputer>
From: "Stephen Colebourne" <scolebourne@btopenworld.com>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
References: <96652FA6-8308-11D6-81CB-003065DC754C@mac.com>
Subject: Re: [Reflect] Summary of points and relationship with BeanUtils
Date: Wed, 19 Jun 2002 01:16:59 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Clearly deserving a careful reply...
When reading this email, note the use of Reflect and Introspect to denote
the two 'concepts' (avoiding the words package or sub project for the
moment). Sub-projects are denoted by [].

----- Original Message -----
From: "robert burrell donkin" <robertdonkin@mac.com>
> > 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.

If in the long term, [BeanUtils] is to depend on Introspect, then Reflect
cannot be in [BeanUtils], as this creates a cyclic dependency (discoraged by
the charter). See my 'magic wand' comments at the end for my solution.

> 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.

In my previous email I indicated that I agreed with these semtiments.
Reflect and Introspect now strike me as two different things. See my 'magic
wand' comments at the end for my solution.

> 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 didn't ask [BeanUtils] to depend on Reflect or Introspect immediately. I
suggested that [BeanUtils] could eventually.

> 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.

And yet other projects are currently choosing not to use those in
[BeanUtils] ([JXpath] springs to mind) and to write their own low level
reflection code. Obviously you don't control other project's decisions, but
the fact that they don't use [BeanUtils] shouldnt be ignored.

> 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.

But Introspect is very much about introspect code. It strikes me that the
only way to meet the requirement in this paragraph is for both Reflect and
Introspect to be folded into [BeanUtils]. Now I definitely don't like that
from a naming point of view, but I could get over a naming issue. I am in
fact more concerned about [BeanUtils] becoming bloated and confused. From
the charter - "Each package must have a clearly defined purpose, scope, and
API -- Do one thing well, and keep your contracts". I already question
whether BeanUtils conforms to that re DynaBeans and ConvertUtils.

> 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.

Agreed, being up front is best here, I will try to express my opinions
clearly too.


Magic wand
------------
So if I had a magic wand, what would I do...(ie. this is intended to be a
bit controversial, but really it is a summary of a lot of things that have
been discussed over the past two weeks or so)

Increase the importance and use of [Lang]
a) copy MethodUtils from [BeanUtils], renamed to Reflection
   - change MethodUtils in [BeanUtils] to forward methods to Reflection in
[Lang] for backwards compatability (NB: wait until the release to do this)
  - add functions to Reflection as they are found (at least one is suggested
from JXpath, I can think of others)
b) move Predicate, Transformer, Closure, Factory and associated utilities
from [Collections]
   - sorry, that breaks compatability in [Collections] but there's no
sensible solution to that, and it is only a package name change
   - [Collections] needs to get back to collections to follow the "Each
package must have a clearly defined purpose, scope, and API -- Do one thing
well, and keep your contracts" mantra.
c) decide on whether the naming convention in [Lang] is xxxs as with Strings
at present, or xxxUtils as with StringUtils (ie. what [Collections] adopted.
d) consider other additions to [Lang]
   - a Serialization class, with a method that clones via serialization
   - a StringBuffer class, with the same methods as Strings, but for a
StringBuffer.
e) release [Lang] as a full commons project
Create a new sandbox subproject [Introspect]
- to do the fancy introspection stuff I've been talking about
- [Introspect] depends on [Lang]

I suspect people's views may be polarised on this section. Both the view 'it
doesn't matter where the code is' and 'its vital as to where the code is'
are opinions that have been expressed on this list. The section above
clearly says I'm in the camp that says commons needs a little refactoring,
even if that might have some (minor) public impact on the API.

Stephen


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>