commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@btopenworld.com>
Subject Re: [clazz] Active Meta Data [Re: [reflect] Proposal: (WAS [BeanUtils] etc...)]
Date Fri, 25 Oct 2002 23:15:53 GMT
From: "Dmitri Plotnikov" <dplotnik@yahoo.com>
> The idea of the original proposal as far as I understand it was to have
> a generic programming model for a variety of kinds of beans and
> adaptors between this generic programming model and the specific
> programming models supported by those beans.

Effectively, yes. A model of a class and its fields, methods and properties
over and above that provided by reflection.

> 1. Factory-based instantiation.  In some cases we cannot simply say:
>
>   Reflection.set(person, "address", new Address("Fun Street"));
>
> We may have to go through a factory to instantiate the property value.
> Perhaps we could use this method signature:
>
>   Reflection.setNew(bean, property, Object factoryId, Object params[]);
>
> example:
>
>   Reflection.setNew(person, "address",
>                    Address.class, new Object[]{"Fun Street"});

Factories will definitely be required:
ClazzUtils.getIClass(Address.class);
would parse Address.class and create the model surrounding it. As a factory
it can cache info.

Where appropriate, I was intending to use the Factory class from [pattern]
for creating objects.


> 2. I think we need to differentiate between collections and iterators.
> The programming model is entirely different.  For a collection we can
> getSize/add/remove.  For an iterator all we can we is iterate.  So I
> suggest we treat these two a different animals.

Not sure how iterators fit into the model.


> 3. Type conversions.  Wouldn't it be nice if the set/add methods did
> type conversion as needed?  DynaBean have that feature now.  If so,
> should type conversion itself be customizable?

My intention would be to create a new project in commons called [convertor]
in which the type convertors reside. (It could alternately be part of
[lang]). The convertors would implement the [pattern] Transformer interface.
Type conversion on sets should probably be optional however.


> 4. Wrapper addaptor vs. Delegate adaptor.  In Ola's proposal the
> programming model adaptor is a delegate.  In DynaBeans it is a wrapper.
>  Which is better?  I am personally in favor of delegate, because of two
> benefits:
>    a) When dealing with object graphs, it is easy to wrap the root,
>    but what do you do with the children?  Case in point:
> WrapperDynaBeans wrap the root, but not property values.
>    b) Why allocate all these stateless objects?  I understand that with
> the new JVMs object allocation is supposed to be very cheap.  Still,
> why create so much transient garbage?

I need to see some code choices to understand this further. Certainly, we
will need to get a decent turn of speed out of this ;-)

Stephen


> - Dmitri
>
>
>
> -- Original message
> Stephen Colebourne wrote on Sun, 16 Jun 2002 11:42:08 -0700
>
> Getting the balance right will be important. I think of Digster here
> (although I must confess to not having actually used it!). Digester
> allows
> different projects to setup rules as to how XML is parsed. Some
> standard
> rules are provided. But projects can add their own (that is the key,
> thus a
> config project can have its own rules).
>
> Your simple flat methods are fine for beans following a strict naming
> convention. But not all _classes_ do. That doesn't mean that there is
> no
> place for an interface like you suggest, but I'm just trying to be fair
> to
> the requirements yet to be gathered.
>
> Stephen
>
> ----- Original Message -----
> From: "Ola Berg" <ola.berg@arkitema.se>
> To: <commons-dev@jakarta.apache.org>
> Sent: Sunday, June 16, 2002 7:52 PM
> Subject: Re: [reflect] Proposal: (WAS [BeanUtils] etc...)
>
>
> > >The multitude of potential users of this component is
> > >huge, they all have
> > >current solutions and they all have some peculiarities about them.
> For
> this
> > >new component to be successful, we will need to address all of those
> > >requirements, which calls for an abstract, configurable and
> customizable
> > >architecture.
> >
> > I don\'t agree. Well, of course there are many users that do a lot of
> stuff in their reflection/introspection packages.
> >
> > But IMO reflect should be a mere utility for easy use of reflection
> (reducing complexity and awkwardness in java.lang.reflect). Other cool
> things (like automatic configuration of beans from command line or
> config
> files) do belong in other packages (both examples above should go in a
> Configuration framework?).
> >
> > Those are _users_ of reflection, they don\'t faciliate reflection in
> themselves. This doesn\'t call for plugable architectures, and if we
> end up
> with it I believe that we have over-engineered them and missed a clean
> separation of concerns.
> >
> > I think of a Reflection class with static methods like
> >
> > Reflection.set( Object bean, String propertyName, Object value);
> >
> > Object o = Reflection.get( Object bean, String propertyName);
> >
> > Reflection.add( Object bean, String propertyName, Object value);
> >
> > Reflection.put( Object bean, String propertyName, Object key, Object
> value);
> >
> > Reflection.set( Object bean, String propertyName, int index, Object
> value);
> >
> > Object result = Reflection.call( Object bean, String methodName,
> Object []
> parameterValues);
> >
> > The internals of a Reflection class could very well use a plugable
> framework for insertion of new handy methods and cached lookup of
> reflection
> Method objects (like all getters in a class etc), and some of this
> functionality should probably be pluggable (for people to insert new
> bean-like naming conventions, maybe using Predicate on methods).
> >
> > But main functionality exposed as handy methods.
> >
> > /O
> >
> > --------------------
> > ola.berg@arkitema.se
> > 0733 - 99 99 17
>
>
> __________________________________________________
> Do you Yahoo!?
> Y! Web Hosting - Let the expert host your web site
> http://webhosting.yahoo.com/
>
> --
> To unsubscribe, e-mail:
<mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:commons-dev-help@jakarta.apache.org>
>


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