You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Stephen Colebourne <sc...@btopenworld.com> on 2002/06/18 00:59:39 UTC
[Reflect] Summary of points and relationship with BeanUtils
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
3) Various people are concerned that a 'large framework' won't suit them (if
it's large it won't suit me either!)
4) There are clearly two levels involved here - reflection helpers and
introspection.
I believe that (4) answers (2) and (3).
Reflect
-------
On quick inspection, BeanUtils' MethodUtils would make a sound base for the
reflection package. Other methods have been suggested too, and they would be
added.
Reflect should be a simple flat static interface just above java reflection.
It should provide those methods that java should but doesn't. It shouldn't
scare anyone and be able to be picked up easily.
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. My hope would
be that BeanUtils would choose to depend on reflect at a later stage.
Introspect
-----------
This is the higher level part that I first laid out in the proposal. If
successful it should tie together JXpath, Betwixt, Joda and maybe BCEL and
BeanUtils. (There are probably others too). It is about class analysis, and
if it fits happily DynaBean type concepts.
I think that once there is some dummy code to look at (to explain my ideas),
it might make a little more sense. Patience!
BeanUtils
----------
I don't think that either reflect or introspect replace BeanUtils. The
purpose of BeanUtils is to assist with a specific case - working with the
java.beans package and the Introspector. This is a perfectly valid case.
Introspect is about saying 'the java beans spec is outdated, and so is
Introspector'.
Naming
--------
Given these two separate layers - reflect and introspect - I'm tempted to
say that either:
- two new sub-projects are needed, or
- reflect should be part of a reinvigorated lang, and the new project is
called 'introspect'
I favour the latter at the moment, as reflect will probably just be one
class and a jar just for that seems pointless.
Stephen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Reflect] Summary of points and relationship with BeanUtils
Posted by Juozas Baliuka <ba...@centras.lt>.
Ok,
I will start a separate project for code generation someday.
I believe everything ok with your "karma", add proposal and code to cvs and
we will start more meaningful work.
> I definitely would like to make BCEL more accesible. However, reflect
cannot
> depend on BCEL.
>
> Stephen
>
> ----- Original Message -----
> From: "Juozas Baliuka" <ba...@mwm.lt>
> To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>;
> "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> Sent: Tuesday, June 18, 2002 10:58 AM
> Subject: Re: [Reflect] Summary of points and relationship with BeanUtils
>
>
> >
> > Hi,
> > As I understand we will have utils for java.lang.reflect.* and new
> > introspection based on reflect utils.
> > You know, I can't find a good place for code generators, this API looks
> > like reflection and uses
> > code generation (BCEL) for implementation. I use this code for
> optimizations
> > and tracing in my "closed" projects and for persistence in simplestore
and
> > XORM.
> > May be put it to this project ?
> >
> > At 23:59 2002.06.17 +0100, 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
> > >3) Various people are concerned that a 'large framework' won't suit
them
> (if
> > >it's large it won't suit me either!)
> > >4) There are clearly two levels involved here - reflection helpers and
> > >introspection.
> > >
> > >I believe that (4) answers (2) and (3).
> > >
> > >Reflect
> > >-------
> > >On quick inspection, BeanUtils' MethodUtils would make a sound base for
> the
> > >reflection package. Other methods have been suggested too, and they
would
> be
> > >added.
> > >
> > >Reflect should be a simple flat static interface just above java
> reflection.
> > >It should provide those methods that java should but doesn't. It
> shouldn't
> > >scare anyone and be able to be picked up easily.
> > >
> > >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. My hope
> would
> > >be that BeanUtils would choose to depend on reflect at a later stage.
> > >
> > >Introspect
> > >-----------
> > >This is the higher level part that I first laid out in the proposal. If
> > >successful it should tie together JXpath, Betwixt, Joda and maybe BCEL
> and
> > >BeanUtils. (There are probably others too). It is about class analysis,
> and
> > >if it fits happily DynaBean type concepts.
> > >
> > >I think that once there is some dummy code to look at (to explain my
> ideas),
> > >it might make a little more sense. Patience!
> > >
> > >BeanUtils
> > >----------
> > >I don't think that either reflect or introspect replace BeanUtils. The
> > >purpose of BeanUtils is to assist with a specific case - working with
the
> > >java.beans package and the Introspector. This is a perfectly valid
case.
> > >Introspect is about saying 'the java beans spec is outdated, and so is
> > >Introspector'.
> > >
> > >
> > >Naming
> > >--------
> > >Given these two separate layers - reflect and introspect - I'm tempted
to
> > >say that either:
> > >- two new sub-projects are needed, or
> > >- reflect should be part of a reinvigorated lang, and the new project
is
> > >called 'introspect'
> > >
> > >I favour the latter at the moment, as reflect will probably just be one
> > >class and a jar just for that seems pointless.
> > >
> > >Stephen
> > >
> > >
> > >--
> > >To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > >For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Reflect] Summary of points and relationship with BeanUtils
Posted by Stephen Colebourne <sc...@btopenworld.com>.
I definitely would like to make BCEL more accesible. However, reflect cannot
depend on BCEL.
Stephen
----- Original Message -----
From: "Juozas Baliuka" <ba...@mwm.lt>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>;
"Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Tuesday, June 18, 2002 10:58 AM
Subject: Re: [Reflect] Summary of points and relationship with BeanUtils
>
> Hi,
> As I understand we will have utils for java.lang.reflect.* and new
> introspection based on reflect utils.
> You know, I can't find a good place for code generators, this API looks
> like reflection and uses
> code generation (BCEL) for implementation. I use this code for
optimizations
> and tracing in my "closed" projects and for persistence in simplestore and
> XORM.
> May be put it to this project ?
>
> At 23:59 2002.06.17 +0100, 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
> >3) Various people are concerned that a 'large framework' won't suit them
(if
> >it's large it won't suit me either!)
> >4) There are clearly two levels involved here - reflection helpers and
> >introspection.
> >
> >I believe that (4) answers (2) and (3).
> >
> >Reflect
> >-------
> >On quick inspection, BeanUtils' MethodUtils would make a sound base for
the
> >reflection package. Other methods have been suggested too, and they would
be
> >added.
> >
> >Reflect should be a simple flat static interface just above java
reflection.
> >It should provide those methods that java should but doesn't. It
shouldn't
> >scare anyone and be able to be picked up easily.
> >
> >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. My hope
would
> >be that BeanUtils would choose to depend on reflect at a later stage.
> >
> >Introspect
> >-----------
> >This is the higher level part that I first laid out in the proposal. If
> >successful it should tie together JXpath, Betwixt, Joda and maybe BCEL
and
> >BeanUtils. (There are probably others too). It is about class analysis,
and
> >if it fits happily DynaBean type concepts.
> >
> >I think that once there is some dummy code to look at (to explain my
ideas),
> >it might make a little more sense. Patience!
> >
> >BeanUtils
> >----------
> >I don't think that either reflect or introspect replace BeanUtils. The
> >purpose of BeanUtils is to assist with a specific case - working with the
> >java.beans package and the Introspector. This is a perfectly valid case.
> >Introspect is about saying 'the java beans spec is outdated, and so is
> >Introspector'.
> >
> >
> >Naming
> >--------
> >Given these two separate layers - reflect and introspect - I'm tempted to
> >say that either:
> >- two new sub-projects are needed, or
> >- reflect should be part of a reinvigorated lang, and the new project is
> >called 'introspect'
> >
> >I favour the latter at the moment, as reflect will probably just be one
> >class and a jar just for that seems pointless.
> >
> >Stephen
> >
> >
> >--
> >To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> >For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Reflect] Summary of points and relationship with BeanUtils
Posted by Juozas Baliuka <ba...@mwm.lt>.
Hi,
As I understand we will have utils for java.lang.reflect.* and new
introspection based on reflect utils.
You know, I can't find a good place for code generators, this API looks
like reflection and uses
code generation (BCEL) for implementation. I use this code for optimizations
and tracing in my "closed" projects and for persistence in simplestore and
XORM.
May be put it to this project ?
At 23:59 2002.06.17 +0100, 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
>3) Various people are concerned that a 'large framework' won't suit them (if
>it's large it won't suit me either!)
>4) There are clearly two levels involved here - reflection helpers and
>introspection.
>
>I believe that (4) answers (2) and (3).
>
>Reflect
>-------
>On quick inspection, BeanUtils' MethodUtils would make a sound base for the
>reflection package. Other methods have been suggested too, and they would be
>added.
>
>Reflect should be a simple flat static interface just above java reflection.
>It should provide those methods that java should but doesn't. It shouldn't
>scare anyone and be able to be picked up easily.
>
>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. My hope would
>be that BeanUtils would choose to depend on reflect at a later stage.
>
>Introspect
>-----------
>This is the higher level part that I first laid out in the proposal. If
>successful it should tie together JXpath, Betwixt, Joda and maybe BCEL and
>BeanUtils. (There are probably others too). It is about class analysis, and
>if it fits happily DynaBean type concepts.
>
>I think that once there is some dummy code to look at (to explain my ideas),
>it might make a little more sense. Patience!
>
>BeanUtils
>----------
>I don't think that either reflect or introspect replace BeanUtils. The
>purpose of BeanUtils is to assist with a specific case - working with the
>java.beans package and the Introspector. This is a perfectly valid case.
>Introspect is about saying 'the java beans spec is outdated, and so is
>Introspector'.
>
>
>Naming
>--------
>Given these two separate layers - reflect and introspect - I'm tempted to
>say that either:
>- two new sub-projects are needed, or
>- reflect should be part of a reinvigorated lang, and the new project is
>called 'introspect'
>
>I favour the latter at the moment, as reflect will probably just be one
>class and a jar just for that seems pointless.
>
>Stephen
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Reflect] Summary of points and relationship with BeanUtils
Posted by Henri Yandell <ba...@generationjava.com>.
Ooops. Had started ignoring this thread as an area I lacked experience in
to discuss. Guess it's grown :)
On Wed, 19 Jun 2002, Stephen Colebourne wrote:
> Increase the importance and use of [Lang]
+1 from me. I've been busy trying to learn CLI/Maven/others so haven't
focused on Lang as much as I need to. I really need to push out a strong
series of unit tests for it.
> 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.
It used to be all xxxUtils and the decision was made to go away from it
when they broke out of the Util sub-project.
> d) consider other additions to [Lang]
> - a Serialization class, with a method that clones via serialization
Heh. Someone wrote an article on this a year or so back and it's
languished in my xxx.lang package ever since. Am happy to begin by
committing that unless someone has a version they've nurtured into
something more useful.
> - a StringBuffer class, with the same methods as Strings, but for a
> StringBuffer.
Sounds good. Seems to me there is a better way though. java.lang.String
and StringBuffer don't share that many functionalities from memory. In
Strings the code either manipulates it as a String, or turns it to a
StringBuffer. I would hope that despite having two classes, there would
really only be one implementation method and one method that redirects.
However these methods would not all live in Strings, or all live in
StringBuffers.
I imagine that the StringBuffer methods would pass in a StringBuffer
expecting that to be modified and not to have a StringBuffer returned?? Or
if one is returned [as often is the case in java.lang.StringBuffer] that
it would return the one passed in.
> e) release [Lang] as a full commons project
Won't argue. Lang seems to be cropping up as a project that a few others
are dependant on, so having a release would be nice.
It would be nice to have more unit tests, mavenise it, doc more, hack out
ugly String overloads. The biggest issue I'm finding as I use the methods
is that a lot aren't null safe.
Once Lang is released, then I can release a 1.0 of String taglib depending
on it. So time for me to focus hard on Lang I think.
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Reflect] Summary of points and relationship with BeanUtils
Posted by robert burrell donkin <ro...@mac.com>.
On Wednesday, June 19, 2002, at 09:27 PM, Stephen Colebourne wrote:
<snip>
> You suggested a vote. I'm not sure at this stage that there is anything to
> vote on?
not really at the stage :)
if i'd wanted a vote, i'd have proposed one. i was simply observing that
votes are a good way to ensure that everybody's opinions are taken into
account - even those not following a particular thread. they can also
serve as useful punctuation to create the end of a discussion.
- robert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Reflect] Summary of points and relationship with BeanUtils
Posted by Henri Yandell <ba...@generationjava.com>.
> Yes, but for the part that suggests low level reflection would be a
> component in its own right. I happen to think that a component with 1 class
> (or at most 3 or 4) is just too small. Thats why I'm pushing for it to go in
> Lang. (Remember, Lang already has some reflection code in the Classes
> class).
Low level reflection into Lang sounds good to me. A component with 1 to
3/4 classes is to small I think and before has often gone into Util. I
currently have some XmlStrings components in Util which will probably
break out if I get enough momentum behind them.
Adding low-Reflect to Lang would also help bulk it out a bit without
compromising any projects proposals.
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Reflect] Summary of points and relationship with BeanUtils
Posted by Stephen Colebourne <sc...@btopenworld.com>.
From: "robert burrell donkin" <ro...@mac.com>
> there seem to be be two distinct types of code (both proposed and
existing)
> : high level alternatives to java beans introspection and low level
> reflection utilities providing the nuts and bolts reused by the higher
> level pseudo-introspection code (including BeanUtils).
>
> two observations:
>
> 1. the core low level reflection utilities need to build on the existing
> work which is currently in released components in the commons (eg.
> beanutils). if we decide to refactor, this code needs to be brought into
> the commons quickly so that we don't branch the code base. (there are
> outstanding bugs and enhancements for beanutils involving the low level
> reflection code).
Agreed, good work has been done and is valued.
> 2. the rest of the proposed reflect package (the higher level stuff) is
> speculative and experimental. this is unlikely to be ready to be promoted
> into the commons any time soon. java bean introspection corresponds to
> this higher stuff and that's why there's resistance to a dependency on
> beanutils for it's low level reflection code.
At present it is speculative (hell I can't even get it into the sandbox at
the moment ;-) And yes it may do a similar job to BeanUtils thus the
undesirability of a dependency.
> i now think that consolidating the code into a single reflect component
> that other components can depend on for low level reflection utilities is
> a good idea but we need to have a plan that allow this component to be
> developed without compromising already released components.
>
> i have a couple of possible ideas (no doubt other people think of others
> if these are found wanting)
>
> A. split reflect between the commons and the sandbox. the low level
> reflection utilities would be pushed by themselves into the commons as
> soon as possible without waiting for the higher level stuff to be
finished.
> the higher level stuff would remain in a project in the sandbox until
it'
> s ready. it could then be consolidated with the low level utilities or
> released as a separate component.
Yes, but for the part that suggests low level reflection would be a
component in its own right. I happen to think that a component with 1 class
(or at most 3 or 4) is just too small. Thats why I'm pushing for it to go in
Lang. (Remember, Lang already has some reflection code in the Classes
class).
> B. keep reflect as a project in the sandbox but manually synchronize the
> classes. primary development of the low level reflection utility classes
> would happen in the sandbox but changes would be copied across into
> versions of these components in beanutils. all bugs fixes and enhancements
> required by beanutils etc. would be done in the source in the sandbox and
> the code would therefore not be branched.
Since I want to see low level reflection separate from the proposed new
introspection code, this makes less sense to me. Also I suspect this option
may prove harder to work in practice.
Stephen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Reflect] Summary of points and relationship with BeanUtils
Posted by robert burrell donkin <ro...@mac.com>.
oop!
(after finally taking some to look read up on the difference, i found that)
i've been using inaccurate nomenclature throughout this entire discussion.
reflection is the act of determining meta data dynamically at run time
for a class and using that information to execute methods and interrogate
fields. whereas introspection is the application of reflection related to
java beans.
all my comments about 'low level introspection' code should really have
been about low level reflection code.
anyway, my apologies...
(there's more at the bottom)
On Thursday, June 20, 2002, at 04:13 AM, Craig R. McClanahan wrote:
<snip>
> There's an existing enhancement request against BeanUtils (in Bugzilla) to
> create a ConstructorUtils analog to the things in MethodUtils -- and there
> is probably some common code that could be factored out between the two,
> so I'd bet we're talking more like three classes than one.
>
> In addition, many of the signatures above seem like *very* low value-add
> over the standard Java APIs -- the most complicated things (looking up the
> right Method object by scanning all the superclasses and implemented
> interfaces/superinterfaces is the important part. Everything else looks
> like syntactic sugar over existing JDK capabiities.
i've taken a look in bugzilla (thanks craig) and had a bit of a think
about stuff.
various components have reflection code. it makes sense to consolidate all
of this code to avoid duplication of effort and so that it can more easily
be re-used.
there seem to be be two distinct types of code (both proposed and existing)
: high level alternatives to java beans introspection and low level
reflection utilities providing the nuts and bolts reused by the higher
level pseudo-introspection code (including BeanUtils).
two observations:
1. the core low level reflection utilities need to build on the existing
work which is currently in released components in the commons (eg.
beanutils). if we decide to refactor, this code needs to be brought into
the commons quickly so that we don't branch the code base. (there are
outstanding bugs and enhancements for beanutils involving the low level
reflection code).
2. the rest of the proposed reflect package (the higher level stuff) is
speculative and experimental. this is unlikely to be ready to be promoted
into the commons any time soon. java bean introspection corresponds to
this higher stuff and that's why there's resistance to a dependency on
beanutils for it's low level reflection code.
i now think that consolidating the code into a single reflect component
that other components can depend on for low level reflection utilities is
a good idea but we need to have a plan that allow this component to be
developed without compromising already released components.
i have a couple of possible ideas (no doubt other people think of others
if these are found wanting)
A. split reflect between the commons and the sandbox. the low level
reflection utilities would be pushed by themselves into the commons as
soon as possible without waiting for the higher level stuff to be finished.
the higher level stuff would remain in a project in the sandbox until it'
s ready. it could then be consolidated with the low level utilities or
released as a separate component.
B. keep reflect as a project in the sandbox but manually synchronize the
classes. primary development of the low level reflection utility classes
would happen in the sandbox but changes would be copied across into
versions of these components in beanutils. all bugs fixes and enhancements
required by beanutils etc. would be done in the source in the sandbox and
the code would therefore not be branched.
comments?
- robert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Reflect] Summary of points and relationship with BeanUtils
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Wed, 19 Jun 2002, Stephen Colebourne wrote:
> Date: Wed, 19 Jun 2002 21:54:34 +0100
> From: Stephen Colebourne <sc...@btopenworld.com>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> Subject: Re: [Reflect] Summary of points and relationship with BeanUtils
>
> From: "Michael A. Smith" <ma...@apache.org>
> > I haven't followed this thread too closely, but I'm not sure where the
> > chicken and egg are. Rather than *moving* the code to lang, you can
> > *copy* it. Then, BeanUtils or whatever can still depend on its own
> > version until the lang version is released. Then, BeanUtils can update
> > (when they're ready) to use the new version that exists in the released
> > version of lang, assuming, of course, that the version in lang is as
> > good, or better, than the version already in BeanUtils.
>
> Actually, this is what I'm arguing for ;)
>
> > btw, I'd prefer if this reflection stuff was in a package other than
> > lang. When I think of the "lang" package, I think of stuff like
> > "Strings", "Integers", etc. "Predicate" "Closure" and "Factory"
> > probably apply there as well. Essentially, the most basic of basic
> > coding stuff that just plainly doesn't exist in the java APIs. Any type
> > of layer over reflection/introspection is a layer above what I view
> > "lang" to be
>
> What I am proposing for Lang is one class, with methods to assist with
> *reflection*, not introspection. Example methods
> - getAllSuperInterfaces(Class)
> - getAllSuperClasses(Class)
> - getAllMethods(Class)
> - getAllFields(Class)
> - getMethodSignature(Method)
> - getMethodPolymorphically(Class, Object[])
> - getClassName(Class)
> - getPackageName(Class)
>
> There will be no reference to beans, or the Introspector class, or
> introspection in general. The class' purpose is methods to assist with the
> java.lang.reflect package. ie. to provide methods that are missing in Java.
> Hence Lang.
>
There's an existing enhancement request against BeanUtils (in Bugzilla) to
create a ConstructorUtils analog to the things in MethodUtils -- and there
is probably some common code that could be factored out between the two,
so I'd bet we're talking more like three classes than one.
In addition, many of the signatures above seem like *very* low value-add
over the standard Java APIs -- the most complicated things (looking up the
right Method object by scanning all the superclasses and implemented
interfaces/superinterfaces is the important part. Everything else looks
like syntactic sugar over existing JDK capabiities.
> Stephen
>
>
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Reflect] Summary of points and relationship with BeanUtils
Posted by Stephen Colebourne <sc...@btopenworld.com>.
No problem with that
----- Original Message -----
From: "Henri Yandell" <ba...@generationjava.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Wednesday, June 19, 2002 9:54 PM
Subject: Re: [Reflect] Summary of points and relationship with BeanUtils
>
> Shoudln't it go in org.apache.commons.lang.reflect??? [if it goes in Lang
> that is].
>
> > > btw, I'd prefer if this reflection stuff was in a package other than
> > > lang. When I think of the "lang" package, I think of stuff like
> > > "Strings", "Integers", etc. "Predicate" "Closure" and "Factory"
> > > probably apply there as well. Essentially, the most basic of basic
> > > coding stuff that just plainly doesn't exist in the java APIs. Any
type
> > > of layer over reflection/introspection is a layer above what I view
> > > "lang" to be
> >
> > What I am proposing for Lang is one class, with methods to assist with
> > *reflection*, not introspection. Example methods
> > - getAllSuperInterfaces(Class)
> > - getAllSuperClasses(Class)
> > - getAllMethods(Class)
> > - getAllFields(Class)
> > - getMethodSignature(Method)
> > - getMethodPolymorphically(Class, Object[])
> > - getClassName(Class)
> > - getPackageName(Class)
> >
> > There will be no reference to beans, or the Introspector class, or
> > introspection in general. The class' purpose is methods to assist with
the
> > java.lang.reflect package. ie. to provide methods that are missing in
Java.
> > Hence Lang.
> >
> > Stephen
> >
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> > For additional commands, e-mail:
<ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Reflect] Summary of points and relationship with BeanUtils
Posted by Henri Yandell <ba...@generationjava.com>.
Shoudln't it go in org.apache.commons.lang.reflect??? [if it goes in Lang
that is].
> > btw, I'd prefer if this reflection stuff was in a package other than
> > lang. When I think of the "lang" package, I think of stuff like
> > "Strings", "Integers", etc. "Predicate" "Closure" and "Factory"
> > probably apply there as well. Essentially, the most basic of basic
> > coding stuff that just plainly doesn't exist in the java APIs. Any type
> > of layer over reflection/introspection is a layer above what I view
> > "lang" to be
>
> What I am proposing for Lang is one class, with methods to assist with
> *reflection*, not introspection. Example methods
> - getAllSuperInterfaces(Class)
> - getAllSuperClasses(Class)
> - getAllMethods(Class)
> - getAllFields(Class)
> - getMethodSignature(Method)
> - getMethodPolymorphically(Class, Object[])
> - getClassName(Class)
> - getPackageName(Class)
>
> There will be no reference to beans, or the Introspector class, or
> introspection in general. The class' purpose is methods to assist with the
> java.lang.reflect package. ie. to provide methods that are missing in Java.
> Hence Lang.
>
> Stephen
>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Reflect] Summary of points and relationship with BeanUtils
Posted by Stephen Colebourne <sc...@btopenworld.com>.
From: "Michael A. Smith" <ma...@apache.org>
> I haven't followed this thread too closely, but I'm not sure where the
> chicken and egg are. Rather than *moving* the code to lang, you can
> *copy* it. Then, BeanUtils or whatever can still depend on its own
> version until the lang version is released. Then, BeanUtils can update
> (when they're ready) to use the new version that exists in the released
> version of lang, assuming, of course, that the version in lang is as
> good, or better, than the version already in BeanUtils.
Actually, this is what I'm arguing for ;)
> btw, I'd prefer if this reflection stuff was in a package other than
> lang. When I think of the "lang" package, I think of stuff like
> "Strings", "Integers", etc. "Predicate" "Closure" and "Factory"
> probably apply there as well. Essentially, the most basic of basic
> coding stuff that just plainly doesn't exist in the java APIs. Any type
> of layer over reflection/introspection is a layer above what I view
> "lang" to be
What I am proposing for Lang is one class, with methods to assist with
*reflection*, not introspection. Example methods
- getAllSuperInterfaces(Class)
- getAllSuperClasses(Class)
- getAllMethods(Class)
- getAllFields(Class)
- getMethodSignature(Method)
- getMethodPolymorphically(Class, Object[])
- getClassName(Class)
- getPackageName(Class)
There will be no reference to beans, or the Introspector class, or
introspection in general. The class' purpose is methods to assist with the
java.lang.reflect package. ie. to provide methods that are missing in Java.
Hence Lang.
Stephen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Reflect] Summary of points and relationship with BeanUtils
Posted by "Michael A. Smith" <ma...@apache.org>.
On Wed, 19 Jun 2002, Craig R. McClanahan wrote:
> > btw, I'd prefer if this reflection stuff was in a package other than
> > lang. When I think of the "lang" package, I think of stuff like
> > "Strings", "Integers", etc. "Predicate" "Closure" and "Factory"
> > probably apply there as well. Essentially, the most basic of basic
> > coding stuff that just plainly doesn't exist in the java APIs. Any type
> > of layer over reflection/introspection is a layer above what I view
> > "lang" to be
> >
> > Then again, I'm probably missing something my not digesting all of the
> > thread first...
> >
>
> My only concern is one that was recently expressed about BeanUtils (which,
> I agree, is primarily focused on JavaBean properties) -- it sounds like
> [lang] runs the risk of bloat and lack of focus also. I'd personally
> rather see small, tightly focused packages for "introspect" and "reflect"
> (and probably some of the other stuff in mind for lang) that can be
> released independently as needed, since the scope of those concepts is
> pretty clear. Chartering a package for "everything that ought to be in
> the standard Java APIs but is not" doesn't seem quite so clear and concise
> .. :-)
ah, but I didn't say "everything that ought to be in the standard Java
APIs but is not." Even paraphrasing, you left off the important part:
"the most basic of basic coding stuff". :)
Oh, and when I said "in a package other than lang" I meant "another
component other than lang".
Although re-reading that now, it certainly doesn't convey the meaning I
was trying for. Put another way, I believe lang should be scoped to
deal with basic manipulating of core java types (primitive and those in
the lang package). I certainly can understand that is still vague and
could still lead to bloat, but let me assure you I don't want to see
that either!
regards,
michael
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Reflect] Summary of points and relationship with BeanUtils
Posted by robert burrell donkin <ro...@mac.com>.
On Thursday, June 20, 2002, at 04:06 AM, Craig R. McClanahan wrote:
>
>
> On Wed, 19 Jun 2002, Michael A. Smith wrote:
>
>> Date: Wed, 19 Jun 2002 15:40:35 -0500 (CDT)
>> From: Michael A. Smith <ma...@apache.org>
>> Reply-To: Jakarta Commons Developers List <commons-
>> dev@jakarta.apache.org>
>> To: Jakarta Commons Developers List <co...@jakarta.apache.org>
>> Subject: Re: [Reflect] Summary of points and relationship with BeanUtils
>>
>> On Wed, 19 Jun 2002, Stephen Colebourne wrote:
>>>> therefore
>>>> code cannot be refactored from existing released components into the
>>>> sandbox.
>>>
>>> I think this is a timing issue. Promoting Lang to Commons will probably
>>> only
>>> occur when Lang is ready for a release. But, for Lang to be ready for a
>>> release it would need to already have the low level reflection code in
>>> it.
>>> Chicken and egg.
>>
>> I haven't followed this thread too closely, but I'm not sure where the
>> chicken and egg are. Rather than *moving* the code to lang, you can
>> *copy* it. Then, BeanUtils or whatever can still depend on its own
>> version until the lang version is released. Then, BeanUtils can update
>> (when they're ready) to use the new version that exists in the released
>> version of lang, assuming, of course, that the version in lang is as
>> good, or better, than the version already in BeanUtils.
>>
>
> This seems like a reasonable compromise approach. If you can convince me
> and the other BeanUtils committers that this will meet our long term needs
> for low level reflection and introspection support, then we'll do what
> Robert suggested -- "delegate and deprecate".
hi craig
this was the original approach which raised my objections in the first
place.
i'm happy to see the code moved from beanutils but i think that it'd be a
bad idea to branch the low level introspection code. i don't want to have
to support two different versions each with their bugs and idiosyncrasies.
let's have just one implementation - and then we'll have a chance of
getting it properly debugged,
- robert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Reflect] Summary of points and relationship with BeanUtils
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Wed, 19 Jun 2002, Michael A. Smith wrote:
> Date: Wed, 19 Jun 2002 15:40:35 -0500 (CDT)
> From: Michael A. Smith <ma...@apache.org>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> Subject: Re: [Reflect] Summary of points and relationship with BeanUtils
>
> On Wed, 19 Jun 2002, Stephen Colebourne wrote:
> > > therefore
> > > code cannot be refactored from existing released components into the
> > > sandbox.
> >
> > I think this is a timing issue. Promoting Lang to Commons will probably only
> > occur when Lang is ready for a release. But, for Lang to be ready for a
> > release it would need to already have the low level reflection code in it.
> > Chicken and egg.
>
> I haven't followed this thread too closely, but I'm not sure where the
> chicken and egg are. Rather than *moving* the code to lang, you can
> *copy* it. Then, BeanUtils or whatever can still depend on its own
> version until the lang version is released. Then, BeanUtils can update
> (when they're ready) to use the new version that exists in the released
> version of lang, assuming, of course, that the version in lang is as
> good, or better, than the version already in BeanUtils.
>
This seems like a reasonable compromise approach. If you can convince me
and the other BeanUtils committers that this will meet our long term needs
for low level reflection and introspection support, then we'll do what
Robert suggested -- "delegate and deprecate".
> btw, I'd prefer if this reflection stuff was in a package other than
> lang. When I think of the "lang" package, I think of stuff like
> "Strings", "Integers", etc. "Predicate" "Closure" and "Factory"
> probably apply there as well. Essentially, the most basic of basic
> coding stuff that just plainly doesn't exist in the java APIs. Any type
> of layer over reflection/introspection is a layer above what I view
> "lang" to be
>
> Then again, I'm probably missing something my not digesting all of the
> thread first...
>
My only concern is one that was recently expressed about BeanUtils (which,
I agree, is primarily focused on JavaBean properties) -- it sounds like
[lang] runs the risk of bloat and lack of focus also. I'd personally
rather see small, tightly focused packages for "introspect" and "reflect"
(and probably some of the other stuff in mind for lang) that can be
released independently as needed, since the scope of those concepts is
pretty clear. Chartering a package for "everything that ought to be in
the standard Java APIs but is not" doesn't seem quite so clear and concise
.. :-)
> regards,
> michael
>
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Reflect] Summary of points and relationship with BeanUtils
Posted by robert burrell donkin <ro...@mac.com>.
On Wednesday, June 19, 2002, at 09:40 PM, Michael A. Smith wrote:
> On Wed, 19 Jun 2002, Stephen Colebourne wrote:
>>> therefore
>>> code cannot be refactored from existing released components into the
>>> sandbox.
>>
>> I think this is a timing issue. Promoting Lang to Commons will probably
>> only
>> occur when Lang is ready for a release. But, for Lang to be ready for a
>> release it would need to already have the low level reflection code in
>> it.
>> Chicken and egg.
>
> I haven't followed this thread too closely, but I'm not sure where the
> chicken and egg are. Rather than *moving* the code to lang, you can
> *copy* it.
-1
i'm personally very concerned about duplicating this particular code. it's
complex and took a long time to get anywhere near reasonably debugged.
(this is where this thread started.)
i think that - in principal - branching the low level introspection
utility code is a very bad idea and would consider vetoing any proposal
which split the low level introspection code base.
> Then, BeanUtils or whatever can still depend on its own
> version until the lang version is released. Then, BeanUtils can update
> (when they're ready) to use the new version that exists in the released
> version of lang, assuming, of course, that the version in lang is as
> good, or better, than the version already in BeanUtils.
unfortunately, there'd be no good way to compare the two competing bodies
of code.
i'd be very reluctant to allow any component i'm involved with to switch
from a well tested code base to a new relatively untested one. also for
compatibility reasons, i'd have to think hard about allowing the two
different competing low level introspection code bases to be used by the
same component. this has unfortunate consequences for stephen's aims.
we'd hoped to find some way around these problems. stephen's plan was to
aim to move the code that would need to be shared into some neutral
component which could be shared between the various higher level
reflection/introspection components. this neutral component needs to be in
the commons and needs to be released (or have a release planned) so that
the existing components can depend on it.
this plan would allow the newer higher level components to grow and
experiment in the sandbox without having to depend on benautils or on
having to branch the low level introspection code base.
- robert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Reflect] Summary of points and relationship with BeanUtils
Posted by "Michael A. Smith" <ma...@apache.org>.
On Wed, 19 Jun 2002, Stephen Colebourne wrote:
> > therefore
> > code cannot be refactored from existing released components into the
> > sandbox.
>
> I think this is a timing issue. Promoting Lang to Commons will probably only
> occur when Lang is ready for a release. But, for Lang to be ready for a
> release it would need to already have the low level reflection code in it.
> Chicken and egg.
I haven't followed this thread too closely, but I'm not sure where the
chicken and egg are. Rather than *moving* the code to lang, you can
*copy* it. Then, BeanUtils or whatever can still depend on its own
version until the lang version is released. Then, BeanUtils can update
(when they're ready) to use the new version that exists in the released
version of lang, assuming, of course, that the version in lang is as
good, or better, than the version already in BeanUtils.
btw, I'd prefer if this reflection stuff was in a package other than
lang. When I think of the "lang" package, I think of stuff like
"Strings", "Integers", etc. "Predicate" "Closure" and "Factory"
probably apply there as well. Essentially, the most basic of basic
coding stuff that just plainly doesn't exist in the java APIs. Any type
of layer over reflection/introspection is a layer above what I view
"lang" to be
Then again, I'm probably missing something my not digesting all of the
thread first...
regards,
michael
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Reflect] Summary of points and relationship with BeanUtils
Posted by Stephen Colebourne <sc...@btopenworld.com>.
From: "robert burrell donkin" <ro...@mac.com>
> released components should not depend on code in the sandbox.
Agreed. (Although I'm sure it has happened)
> therefore
> code cannot be refactored from existing released components into the
> sandbox.
I think this is a timing issue. Promoting Lang to Commons will probably only
occur when Lang is ready for a release. But, for Lang to be ready for a
release it would need to already have the low level reflection code in it.
Chicken and egg.
Now we could promote Lang to commons proper now and not release it - but
that doesn't strike me as the right approach, and its not ready yet. It
strikes me that the process of gathering useful low level reflection methods
into one class in Lang is best done while that Lang is still in the sandbox.
It just gives us greater elbow room in the refactoring.
> what we're talking about here are the low level introspection utilities
> which (in the main) already exist in the released commons components and
> which have been tested and debugged. the point is that components will be
> able to depend on lang rather than on the projects where the code
> currently lives.
>
> experiments on reflection and introspection can still happen in the
> sandbox but they'll build on the solid, release-quality low level
> introspection utilities contained in the commons proper.
I would agree with this if it was "experiments on reflection and
introspection can still happen in the sandbox but they'll build on the
solid, release-quality low level *reflection* utilities contained in the
commons proper." I am arguing that introspection will be the role of
BeanUtils and Introspect. This distinction is important to me.
You suggested a vote. I'm not sure at this stage that there is anything to
vote on?
Stephen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Reflect] Summary of points and relationship with BeanUtils
Posted by robert burrell donkin <ro...@mac.com>.
On Wednesday, June 19, 2002, at 08:14 PM, Juozas Baliuka wrote:
>
> <snip>
>> how i would personally approach this would be by calling a series of
> [VOTE]
>> s as a way of assembling a consensus for your plan. i believe that the
>> first necessary step would be to prepare lang for promotion to the
> commons.
>> if lang cannot achieve promotion, then the low level introspection
>> methods cannot be moved into there.
> It is good to start work in sandbox, it will be more freedom for
> experiments
> on introspection.We have nothing very useful for commons to publish at
> this
> time.
released components should not depend on code in the sandbox. therefore
code cannot be refactored from existing released components into the
sandbox.
what we're talking about here are the low level introspection utilities
which (in the main) already exist in the released commons components and
which have been tested and debugged. the point is that components will be
able to depend on lang rather than on the projects where the code
currently lives.
experiments on reflection and introspection can still happen in the
sandbox but they'll build on the solid, release-quality low level
introspection utilities contained in the commons proper.
- robert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Reflect] Summary of points and relationship with BeanUtils
Posted by Juozas Baliuka <ba...@centras.lt>.
<snip>
> how i would personally approach this would be by calling a series of
[VOTE]
> s as a way of assembling a consensus for your plan. i believe that the
> first necessary step would be to prepare lang for promotion to the
commons.
> if lang cannot achieve promotion, then the low level introspection
> methods cannot be moved into there.
It is good to start work in sandbox, it will be more freedom for experiments
on introspection.We have nothing very useful for commons to publish at this
time.
>
> - robert
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Reflect] Summary of points and relationship with BeanUtils
Posted by robert burrell donkin <ro...@mac.com>.
On Wednesday, June 19, 2002, at 07:26 PM, Stephen Colebourne wrote:
<snip>
> Robert, do you accept that [Lang] could/should/will be a home for low
> level
> 'dumb' reflection helpers?
i have no objections provided that it meets my three criteria :)
i believe that what this means (in practice) is that you need to be able
to get lang promoted to the commons before the code can be moved and the
methods in beanutils deprecated. then a release for lang needs to be cut
as quickly as possible for beanutils to depend on.
how i would personally approach this would be by calling a series of [VOTE]
s as a way of assembling a consensus for your plan. i believe that the
first necessary step would be to prepare lang for promotion to the commons.
if lang cannot achieve promotion, then the low level introspection
methods cannot be moved into there.
- robert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Reflect] Summary of points and relationship with BeanUtils
Posted by Stephen Colebourne <sc...@btopenworld.com>.
From: "robert burrell donkin" <ro...@mac.com>
> my major concerns about the low level introspection code are:
>
> a. we should not duplicate the introspection code
>
> b. the introspection code should be in a component which:
>
> 1. is in the commons proper
> 2. is released now (or will be released very soon)
> 3. has very few dependencies
[Lang] complies to 3, hopefully will comply to 2, and thus complies to 1.
> > The section above
> > clearly says I'm in the camp that says commons needs a little
refactoring,
>
> refactoring makes sense but it should be done in a way that minimizes the
> impact on released components. the refactored code must be made available
> in released components (rather than in the sandbox).
>
> > even if that might have some (minor) public impact on the API.
>
> there's no reason why it should have any impact on the public API. the
> usual house policy is that we delegate and deprecate.
This comment was directed at Predicate, Transformer and Closure in
[collections]. (If they were to move to [Lang] - where they should be - this
change would not be backwardsly compatable (sensibly)). Actually, having
just written that, I think I now know how it could be back compat ;-)
[BeanUtils] MethodUtils can be easily deprecated were a move to [Lang] to
take place. The methods would just forward to the new class. Thus no pubic
API change.
One thing to bear in mind is that [Lang] already has reflection code in
Classes. Its not the most obvious class name, so I didn't spot it at first.
Robert, do you accept that [Lang] could/should/will be a home for low level
'dumb' reflection helpers?
Note: At the moment I'm holding off creating a new sandbox component until
this thread reaches some form of conclusion.
Stephen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Reflect] Summary of points and relationship with BeanUtils
Posted by robert burrell donkin <ro...@mac.com>.
On Wednesday, June 19, 2002, at 01:16 AM, Stephen Colebourne wrote:
<snip>
> 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.
i subscribe to both views :)
my major concerns about the low level introspection code are:
a. we should not duplicate the introspection code
b. the introspection code should be in a component which:
1. is in the commons proper
2. is released now (or will be released very soon)
3. has very few dependencies
> The section above
> clearly says I'm in the camp that says commons needs a little refactoring,
refactoring makes sense but it should be done in a way that minimizes the
impact on released components. the refactored code must be made available
in released components (rather than in the sandbox).
> even if that might have some (minor) public impact on the API.
there's no reason why it should have any impact on the public API. the
usual house policy is that we delegate and deprecate.
- robert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Reflect] Summary of points and relationship with BeanUtils
Posted by Stephen Colebourne <sc...@btopenworld.com>.
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" <ro...@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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Reflect] Summary of points and relationship with BeanUtils
Posted by robert burrell donkin <ro...@mac.com>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>