[clazz] Active Meta Data [Re: [reflect] Proposal: (WAS [BeanUtils] etc...)]

[Dmitri Plotnikov <dp...@yahoo.com>]

I'd like to resurrect a thread we dropped in June.

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.

If do want to go down that path (which I think we should), we will need
to carefully define that programming model.  There are several issues
we'll need to address.

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"});


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.

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?

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?

- 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" <ol...@arkitema.se>
To: <co...@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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [clazz] Active Meta Data [Re: [reflect] Proposal: (WAS [BeanUtils] etc...)]

[Stephen Colebourne <sc...@btopenworld.com>]

From: "Dmitri Plotnikov" <dp...@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" <ol...@arkitema.se>
> To: <co...@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:
<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>