Dmitri Plotnikov wrote:
Berin,
----- Original Message -----
From: "Berin Loritsch" <[EMAIL PROTECTED]>
To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]>
Sent: Friday, October 25, 2002 11:57 PM
Subject: Re: [clazz] Type-based or instance-based metadata?
Dmitri Plotnikov wrote:
Another dilemma we'll have to resolve is whether metadata will be
type-based, instance-based or both.
<skip/>
Most meta info that is useful is type based, not instance based.
I guess my examples are not very convincing. What I am trying to say is
that type-based metadata is only as detailed as the type. For example, if
you declare a property as "int" you have said quite a bit about the
property, however if you declare it as "Object" you have said almost
nothing. Better yet, all DynaBeans are of the same type - DynaBean.
Looking at the type says nothing at all. Same with Map.
What you are looking at is instance based reflection info. Not a more
generic meta info.
First, we do want to have more metadata than mere reflection. We would like
to capture information on how to store XML with Betwixt or JAXB, how to
access objects with JXPath etc.
Second, we are looking to support a wider variety of object models than can
be supported via Java reflection alone (DynaBeans, Maps etc)
Then focus on an "extension" of the Class object (I know it is declared final,
so inheritance is out of the question), that has a set of "attributes". These
attributes mean different things to different people/contexts. Also, don't think
of attributes as a simple name=value pair. C# attributes have the concept of
parameters as well as the attribute itself. For example:
/**
* @avalon:component
* @avalon:role=org.apache.excalibur.DataSourceComponent
* @avalon:creation-policy=singleton
* @test:multi-value=value1,value2,value3
*/
This would declare a class to have the "avalon:component" attribute, the
"avalon:role" attribute with the value set to "org.apache.excalibur.DataSourceComponent",
etc.
These attributes can be read from the IClass (BTW, I hate prefixed interfaces/etc.--
interfaces should be your primary type, so if we have any idioms put it on the
implementing class). Attributes that are method specific would be put in the
javadoc for your method. In your case you want to know the type info for a DynaBean
return value:
/**
* @dynabean:return=java.util.Date
*/
Object getDate();
You would want the "dynabean:return" attribute for the "getDate()" IMethod, or whatever
you call it.
The Attribute approach is very simple, and is easy to use. Its meaning only gives
purpose based on the context. The "test:multi-value" attribute in the first example
would be used in a testing framework so that you can apply the same unit test for a
suite of methods/classes--and they don't even have to set up the same interface (the
Delegate stuff can take care of it). In fact using attributes is a great way to
*generate* JUnit tests automagically!
Meta info that is useful to me is things like this:
* Creation policy (pooled components, thread local components, singleton
components, etc.)
Agreed.
* Required components (i.e. when one component requires a component of
another type)
Could you provide more details on this one?
In Avalon components can require other components to function. An example
would be the DatabaseReader from Cocoon. It reads information from a database,
but uses the org.apache.avalon.excalibur.DataSourceComponent to get the connection
from a pool. By declaring this dependency up front, the attributes for the class
would enable a container to ensure that an implementation of the required component
existed. If it did not, the container can post a failure notice immediately that
makes sense.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <mailto:commons-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@;jakarta.apache.org>
