commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitri Plotnikov <dmi...@apache.org>
Subject Re: [clazz] draft reflect implementation
Date Sat, 09 Nov 2002 22:09:55 GMT
Victor,

----- Original Message -----
From: "Dmitri Plotnikov" <dmitri@apache.org>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Sent: Saturday, November 09, 2002 4:15 PM
Subject: Re: [clazz] draft reflect implementation


>
> ----- Original Message -----
> From: "Victor Volle" <victor.volle@gmxpro.net>
> To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
> Sent: Saturday, November 09, 2002 12:22 PM
> Subject: Re: [clazz] draft reflect implementation
>
>
> > Dmitri,
<snip/>

> >
> > There are (currently) two things I do not
> > quite understand. As far as I can see,
> > all Introspectors scan the complete
> > set of available methods. Would it be possible
> > to have a list of (pluggable) introspectors like and
> > a single loop over all methods. Something like this:
> >
> >         for (int mc = 0; mc < methods.length; mc++){
> >             Method method = methods[mc];
> >             for ( int ic = 0; ic < introspectors.length; ic++ ) {
> >                  ReflectedPropertyIntrospector inspector =
inspectors[mc];
> >                  inspector.checkMethod( method, ..., parseResults );
> >              }
> >         }
> I will consider this very seriously.  I think it is a good idea.
I just remembered why I did the way I did.  The concern is about methods
that may belong to more than one kind of property.  For example,
"removeFoo(Object)" can be a method of either List or Mapped property.
Let's say the "remove" method is the first one encountered in the class.  It
needs to be given to both introspectors: List and Mapped.  If later a method
like "getFoo(int)" is encountered, the property is classified as a List, if
a method like "getFoo(Object)" shows up, the property is a Mapped one.

To resolve this issue we have three options:

1. We let each Introspector examine each method in the order of priority
among introspectors.  This allows each introspector to complete its analysis
of the whole class and get the complete picture to identify all properties.
That's the current solution.

2. We iterate over methods giving them to each introspector.  That's your
solution.  It will only improve performance if we reduce the number of
introspectors looking at each method.  So, we let an introspector tells us
not to bother with other introspectors if it has conclusively recognized it.
For example, if the method is "getFoo(int)", the List introspector will
claim it and we can skip all other introspectors for this method.  Each
introspector will decide for each method whether it "owns" it exclusively or
it may also be recognized by other introspectors.

The latter approach is a worthy optimization, but it introduces an implicit
dependency between introspectors - an introspector will need the knowledge
of what might be of interest to other introspectors.  Also, it is a little
less flexible, because it does not allow for an individual introspector to
do something different, like sort methods or search for them using
class.getMethod(...).

I think this needs a little more analysis.

<snip/>

- Dmitri


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