You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Dmitri Plotnikov <dp...@yahoo.com> on 2002/10/25 20:35:03 UTC
[clazz] Type-based or instance-based metadata?
Another dilemma we'll have to resolve is whether metadata will be
type-based, instance-based or both.
Here's what I am talking about:
Let's say we have this class:
class Address {
public Object getStreet(){ return new String[]{"555", "Sole Pike"}; }
public Comparable getCity() { return "Chipsburg"; }
}
Type-based introspection (like java.beans.Introspector) will tell us
that "street" is a property of type "Object" and "city" has type
"Comparable".
Instance-based introspection will give us "String[]" and "String"
respectively.
Question: is "street" a collection (indexed) property? From the type's
prospective it is not, from the instance prospective it is.
Let's say we are looking at a DynaBean. The class of this object is,
say, WrapDynaBean. What properties does it have? We don't know 'till
we ask the _instance_ getDynaClass() and then interrogate the
DynaClass.
This distinction becomes even more apparent when we are dealing with
Maps. For maps, the only way to find out the type of a property is to
actually get the property value and look at it.
IMO, we should have both kinds of APIs. Something like this:
abstract class MetaDataProvider {
// Override this to return type-based metadata
PropertyMetaData getPropertyMetaDataForType(Object type, String
propertyName){
return null;
}
// Override this to return instance-based metadata
PropertyMetaData getPropertyMetaData(Object instance, String
propertyName){
return getPropertyMetaDataForType(instance.getClass());
}
}
What do you think?
- Dmitri
__________________________________________________
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] Doclet for metadata? (was: Type-based or instance-based metadata?)
Posted by Steve Downey <st...@netfolio.com>.
I suggest that it be one mechanism for creating the meta-data class.
We've got two issues to consider.
1) How to create the meta-data class/classes
2) What the meta-data class looks like
[OK, that looks blindingly obvious to me, now that it's down on pixels]
Doclets are a compile time mechanism. I'd like to see things also be able to
be delayed until deploy or run-time.
I think exploring what meta-data will be exposed might help drive the nature
of the mechanisms for exposing the meta-data.
On Saturday 26 October 2002 05:54 pm, Dmitri Plotnikov wrote:
> I appreciate the power of attributes and I think we should consider
> supporting them very seriously. But before we do that, we need to figure
> out the hourse-cart relationship between [clazz] and doclet-based metadata.
>
> Will doclets be *the* design for [clazz] or *a* pluggable implementation?
>
> If we choose to commit [clazz] to the doclet approach,
>
> 1. We have to have source code processing as a mandated part of the build
> process.
> 2. We cannot add or modify metadata for pre-existing or code-generated
> classes.
> 3. We still haven't answered the requirements for DynaBeans, Maps where
> there is no source code to augment with doclets.
>
> IMO, we should allow a doclet-based plug-in, but it should be a
> specialization of a more generic mechanism.
>
> - Dmitri
>
>
> ----- Original Message -----
> From: "Berin Loritsch" <bl...@apache.org>
> To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> Sent: Saturday, October 26, 2002 4:33 PM
> Subject: Re: [clazz] Type-based or instance-based metadata?
>
> > Dmitri Plotnikov wrote:
> > > Berin,
> > >
> > > ----- Original Message -----
> > > From: "Berin Loritsch" <bl...@apache.org>
> > > To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> > > 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:
>
> <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: [clazz] Type-based or instance-based metadata? Take II
Posted by Dmitri Plotnikov <dp...@yahoo.com>.
--- Victor Volle <vi...@gmxpro.net> wrote:
> > a) We introduce all those methods suggested by Victor Volle:
>
> It was never meant as a suggestion but rather as a "beware" :-)
>
> > boolean isIndexed();
> > boolean isMapped();
> > boolean isListed(); // I would call it
> "isUnorderedCollection"
> >
> > we keep all access methods and throw an exception when the wrong
> one is
> > called.
> >
> >
> > b) We follow what I think is Berin's suggestion (admittedly I don't
> always
> > understand them - I am not a native speaker of English, C# and
> Avalon),
> >
> > Anyway, my understanding is that the idea is to have these methods:
> >
> > field.getAttributeMethod(), // Type based
> > field.getAttributeMethod(Object instance) // Instance based
> >
> > which return one of the following
> > BasicAttributeMethod
> > IndexedAttributeMethod
> > MappedAttributeMethod
> > UnorderedCollectionAttributeMethod
> > IterationAttributeMethod
> >
> > (names would have to be fixed up)
> >
> > Each of these would have methods specific to the corresponding way
> of
> > manipulating the attribute. For example,
> >
> > class BasicAttributeMethod {
> > Object get(Object instance);
> > void set(Object instance, Object value);
> > Object setNew(Object instance, Clazz clazz, Object[]
> parameters);
> > }
> >
> > class IndexedAttributeMethod {
> > int getSize(Object instance);
> > Object get(Object instance, int index);
> > void set(Object instance, int index, Object value);
> > Object setNew(Object instance, int index, Clazz clazz, Object[]
> > parameters);
> > }
> >
> > etc.
> >
> > I think (b) is the nicer of the two appoaches.
>
> that would mean calling "instanceof".
> I do not like either solution.
I know...
> Anyway, I would also tend to solution b) if we throw
> in the method add() for Indexed and (Un)orderedCollection.
> (Lists are not unordered, Sets are. What about
> CollectionAttribute and make IndexedAttribute a subclass?)
Sure.
> Victor
- Dmitri
__________________________________________________
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] Type-based or instance-based metadata? Take II
Posted by Victor Volle <vi...@gmxpro.net>.
> a) We introduce all those methods suggested by Victor Volle:
It was never meant as a suggestion but rather as a "beware" :-)
> boolean isIndexed();
> boolean isMapped();
> boolean isListed(); // I would call it "isUnorderedCollection"
>
> we keep all access methods and throw an exception when the wrong one is
> called.
>
>
> b) We follow what I think is Berin's suggestion (admittedly I don't always
> understand them - I am not a native speaker of English, C# and Avalon),
>
> Anyway, my understanding is that the idea is to have these methods:
>
> field.getAttributeMethod(), // Type based
> field.getAttributeMethod(Object instance) // Instance based
>
> which return one of the following
> BasicAttributeMethod
> IndexedAttributeMethod
> MappedAttributeMethod
> UnorderedCollectionAttributeMethod
> IterationAttributeMethod
>
> (names would have to be fixed up)
>
> Each of these would have methods specific to the corresponding way of
> manipulating the attribute. For example,
>
> class BasicAttributeMethod {
> Object get(Object instance);
> void set(Object instance, Object value);
> Object setNew(Object instance, Clazz clazz, Object[] parameters);
> }
>
> class IndexedAttributeMethod {
> int getSize(Object instance);
> Object get(Object instance, int index);
> void set(Object instance, int index, Object value);
> Object setNew(Object instance, int index, Clazz clazz, Object[]
> parameters);
> }
>
> etc.
>
> I think (b) is the nicer of the two appoaches.
that would mean calling "instanceof".
I do not like either solution.
Anyway, I would also tend to solution b) if we throw
in the method add() for Indexed and (Un)orderedCollection.
(Lists are not unordered, Sets are. What about
CollectionAttribute and make IndexedAttribute a subclass?)
Victor
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [clazz] Type-based or instance-based metadata? Take II
Posted by Dmitri Plotnikov <dm...@apache.org>.
Thanks for reminding me. Yes I did work with PL/I and figuring out the
meaning of conversion from FIXED(13, 4) to FIXED(12, 5) was a little too
much fun.
I agree with the sentiment. Let's not make the conversions too flexible to
be debuggable.
I think there are at least two alternative designs:
a) We introduce all those methods suggested by Victor Volle:
boolean isIndexed();
boolean isMapped();
boolean isListed(); // I would call it "isUnorderedCollection"
we keep all access methods and throw an exception when the wrong one is
called.
b) We follow what I think is Berin's suggestion (admittedly I don't always
understand them - I am not a native speaker of English, C# and Avalon),
Anyway, my understanding is that the idea is to have these methods:
field.getAttributeMethod(), // Type based
field.getAttributeMethod(Object instance) // Instance based
which return one of the following
BasicAttributeMethod
IndexedAttributeMethod
MappedAttributeMethod
UnorderedCollectionAttributeMethod
IterationAttributeMethod
etc
(names would have to be fixed up)
Each of these would have methods specific to the corresponding way of
manipulating the attribute. For example,
class BasicAttributeMethod {
Object get(Object instance);
void set(Object instance, Object value);
Object setNew(Object instance, Clazz clazz, Object[] parameters);
}
class IndexedAttributeMethod {
int getSize(Object instance);
Object get(Object instance, int index);
void set(Object instance, int index, Object value);
Object setNew(Object instance, int index, Clazz clazz, Object[]
parameters);
}
etc.
I think (b) is the nicer of the two appoaches.
- Dmitri
----- Original Message -----
From: "Steve Downey" <st...@netfolio.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Sunday, October 27, 2002 12:17 AM
Subject: Re: [clazz] Type-based or instance-based metadata? Take II
Have you ever worked with PL/I ?
It had features that allowed for automatic promotions/demotions and
conversions similar to what you're calling out here. And they can be useful.
But they also allow a lot of unintended consequences.
Not throwing it out out of hand, but I'm not sure catching exceptions and
trying something else is better than inspecting the exact signature.
On Saturday 26 October 2002 06:20 pm, Dmitri Plotnikov wrote:
> After some thinking the conclusion is - forget it, we cannot do
> instance-based metadata. Too many lookups, no possibility of caching and
> generally too much reflection work.
>
> So, how do we resolve the issue that sometimes we don't know if a property
> is indexed/mapped until runtime?
>
> Here's a revolutionary proposal:
>
> Let's do away with the distinction between indexed and mapped properties
> (as well as parameterized attributes). Wait, before you tear up this
> letter, hear me out!
>
> What if we allowed access to *any* property with *any* of these
mechanisms:
> scalar, indexed, mapped (and maybe parameterized)?
>
> Let's say we have this class:
>
> class Foo {
> String getScalar()...
> void setScalar(String)...
> String[] getArray()...
> void setArray(int, String)...
> }
>
> Why not allow all of the following:
>
> ClazzUtils.get(foo, "scalar"); // returns foo
> ClazzUtils.get(foo, "scalar", 0); // returns foo
> ClazzUtils.get(foo, "scalar", 1); // throws exception "array out of
bounds"
> ClazzUtils.get(foo, "array"); // returns the array
> ClazzUtils.get(foo, "array", 1); // returns array[1]
> ClazzUtils.set(foo, "array", "bar"); // throws exception: "must supply
> index"
> ClazzUtils.get(foo, "array", "aKey"); // throws exception: "not a map"
> ClazzUtils.get(foo, "array", "0"); // maybe returns array[0]?
>
> This way we don't have to know much about a property upfront in order to
> access it. The actual figuring out is put off 'till the act of access.
>
> What do you think?
>
> - Dmitri
>
>
> ----- Original Message -----
> From: "Berin Loritsch" <bl...@apache.org>
> To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> Sent: Saturday, October 26, 2002 4:33 PM
> Subject: Re: [clazz] Type-based or instance-based metadata?
>
> > Dmitri Plotnikov wrote:
> > > Berin,
> > >
> > > ----- Original Message -----
> > > From: "Berin Loritsch" <bl...@apache.org>
> > > To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> > > 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:
>
> <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: [clazz] Type-based or instance-based metadata? Take II
Posted by Steve Downey <st...@netfolio.com>.
Have you ever worked with PL/I ?
It had features that allowed for automatic promotions/demotions and
conversions similar to what you're calling out here. And they can be useful.
But they also allow a lot of unintended consequences.
Not throwing it out out of hand, but I'm not sure catching exceptions and
trying something else is better than inspecting the exact signature.
On Saturday 26 October 2002 06:20 pm, Dmitri Plotnikov wrote:
> After some thinking the conclusion is - forget it, we cannot do
> instance-based metadata. Too many lookups, no possibility of caching and
> generally too much reflection work.
>
> So, how do we resolve the issue that sometimes we don't know if a property
> is indexed/mapped until runtime?
>
> Here's a revolutionary proposal:
>
> Let's do away with the distinction between indexed and mapped properties
> (as well as parameterized attributes). Wait, before you tear up this
> letter, hear me out!
>
> What if we allowed access to *any* property with *any* of these mechanisms:
> scalar, indexed, mapped (and maybe parameterized)?
>
> Let's say we have this class:
>
> class Foo {
> String getScalar()...
> void setScalar(String)...
> String[] getArray()...
> void setArray(int, String)...
> }
>
> Why not allow all of the following:
>
> ClazzUtils.get(foo, "scalar"); // returns foo
> ClazzUtils.get(foo, "scalar", 0); // returns foo
> ClazzUtils.get(foo, "scalar", 1); // throws exception "array out of bounds"
> ClazzUtils.get(foo, "array"); // returns the array
> ClazzUtils.get(foo, "array", 1); // returns array[1]
> ClazzUtils.set(foo, "array", "bar"); // throws exception: "must supply
> index"
> ClazzUtils.get(foo, "array", "aKey"); // throws exception: "not a map"
> ClazzUtils.get(foo, "array", "0"); // maybe returns array[0]?
>
> This way we don't have to know much about a property upfront in order to
> access it. The actual figuring out is put off 'till the act of access.
>
> What do you think?
>
> - Dmitri
>
>
> ----- Original Message -----
> From: "Berin Loritsch" <bl...@apache.org>
> To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> Sent: Saturday, October 26, 2002 4:33 PM
> Subject: Re: [clazz] Type-based or instance-based metadata?
>
> > Dmitri Plotnikov wrote:
> > > Berin,
> > >
> > > ----- Original Message -----
> > > From: "Berin Loritsch" <bl...@apache.org>
> > > To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> > > 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:
>
> <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: [clazz] Doclet for metadata? (was: Type-based or instance-based metadata?)
Posted by Stephen Colebourne <sc...@btopenworld.com>.
From: "Dmitri Plotnikov" <dm...@apache.org>
> I appreciate the power of attributes and I think we should consider
> supporting them very seriously. But before we do that, we need to figure
> out the hourse-cart relationship between [clazz] and doclet-based
metadata.
>
> Will doclets be *the* design for [clazz] or *a* pluggable implementation?
One implementation. Sun will add their own at some point from the JSR. We
will have alternative implementations from BeanInfo, xml files, ...
Also, it needs to be possible to add/update the metadata at runtime.
Stephen
> If we choose to commit [clazz] to the doclet approach,
>
> 1. We have to have source code processing as a mandated part of the build
> process.
> 2. We cannot add or modify metadata for pre-existing or code-generated
> classes.
> 3. We still haven't answered the requirements for DynaBeans, Maps where
> there is no source code to augment with doclets.
>
> IMO, we should allow a doclet-based plug-in, but it should be a
> specialization of a more generic mechanism.
>
> - Dmitri
>
>
> ----- Original Message -----
> From: "Berin Loritsch" <bl...@apache.org>
> To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> Sent: Saturday, October 26, 2002 4:33 PM
> Subject: Re: [clazz] Type-based or instance-based metadata?
>
>
> > Dmitri Plotnikov wrote:
> > > Berin,
> > >
> > > ----- Original Message -----
> > > From: "Berin Loritsch" <bl...@apache.org>
> > > To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> > > 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:
> <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: [clazz] Doclet for metadata? (was: Type-based or instance-based
metadata?)
Posted by Berin Loritsch <bl...@apache.org>.
Dmitri Plotnikov wrote:
> I appreciate the power of attributes and I think we should consider
> supporting them very seriously. But before we do that, we need to figure
> out the hourse-cart relationship between [clazz] and doclet-based metadata.
>
> Will doclets be *the* design for [clazz] or *a* pluggable implementation?
Think of the finished product not in "doclet" style implementations, but in
the bytecode/dynamicly generated metainfo that is stored in/with the source
class.
The "doclet" is only one way of generating the attributes. You can also do
so with BCEL. In fact, BCEL would probably be used to generate the new
IClass implementation for the attribute enabled classes.
> If we choose to commit [clazz] to the doclet approach,
>
> 1. We have to have source code processing as a mandated part of the build
> process.
This can be applied in an ANT task.
> 2. We cannot add or modify metadata for pre-existing or code-generated
> classes.
Sure you can. You would create the ClazzGenerator that would generate the
Class implementation that accesses the attributes. The Doclet would use the
ClazzGenerator as one way of generating the attributes. We would probably
have to use BCEL to generate the attribute classes.
> 3. We still haven't answered the requirements for DynaBeans, Maps where
> there is no source code to augment with doclets.
We don't need source code. We should never require the sourcecode to exist
for the system.
>
> IMO, we should allow a doclet-based plug-in, but it should be a
> specialization of a more generic mechanism.
>
It is merely one face or facade that uses the central mechanism.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [clazz] Doclet for metadata? (was: Type-based or instance-based metadata?)
Posted by Adam Murdoch <ad...@apache.org>.
Doclets wouldn't be the implementation per se. Doclets are really just a
convenience for generating whatever needs to end up in the jar (or classpath
or whatever), whether that's a BeanInfo class, or an XML descriptor, or
whatever. That same info could also be added manually to the jar without
needing to use the doclet or having access to the source.
You could have a single implementation, that has a doclet frontend, or
multiple implementations, each with their own doclet frontend. Or no
doclet, or multiple frontends. You get the idea.
Regardless, +1 for pluggable implementations.
> -----Original Message-----
> From: Dmitri Plotnikov [mailto:dmitri@apache.org]
> Sent: Sunday, 27 October 2002 7:55 AM
> To: Jakarta Commons Developers List
> Subject: Re: [clazz] Doclet for metadata? (was: Type-based or
> instance-based metadata?)
>
>
> I appreciate the power of attributes and I think we should consider
> supporting them very seriously. But before we do that, we need to figure
> out the hourse-cart relationship between [clazz] and doclet-based
> metadata.
>
> Will doclets be *the* design for [clazz] or *a* pluggable implementation?
>
> If we choose to commit [clazz] to the doclet approach,
>
> 1. We have to have source code processing as a mandated part of the build
> process.
> 2. We cannot add or modify metadata for pre-existing or code-generated
> classes.
> 3. We still haven't answered the requirements for DynaBeans, Maps where
> there is no source code to augment with doclets.
>
> IMO, we should allow a doclet-based plug-in, but it should be a
> specialization of a more generic mechanism.
>
> - Dmitri
>
>
> ----- Original Message -----
> From: "Berin Loritsch" <bl...@apache.org>
> To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> Sent: Saturday, October 26, 2002 4:33 PM
> Subject: Re: [clazz] Type-based or instance-based metadata?
>
>
> > Dmitri Plotnikov wrote:
> > > Berin,
> > >
> > > ----- Original Message -----
> > > From: "Berin Loritsch" <bl...@apache.org>
> > > To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> > > 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:
> <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: [clazz] Doclet for metadata? (was: Type-based or instance-based
metadata?)
Posted by Dmitri Plotnikov <dm...@apache.org>.
I appreciate the power of attributes and I think we should consider
supporting them very seriously. But before we do that, we need to figure
out the hourse-cart relationship between [clazz] and doclet-based metadata.
Will doclets be *the* design for [clazz] or *a* pluggable implementation?
If we choose to commit [clazz] to the doclet approach,
1. We have to have source code processing as a mandated part of the build
process.
2. We cannot add or modify metadata for pre-existing or code-generated
classes.
3. We still haven't answered the requirements for DynaBeans, Maps where
there is no source code to augment with doclets.
IMO, we should allow a doclet-based plug-in, but it should be a
specialization of a more generic mechanism.
- Dmitri
----- Original Message -----
From: "Berin Loritsch" <bl...@apache.org>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Saturday, October 26, 2002 4:33 PM
Subject: Re: [clazz] Type-based or instance-based metadata?
> Dmitri Plotnikov wrote:
> > Berin,
> >
> > ----- Original Message -----
> > From: "Berin Loritsch" <bl...@apache.org>
> > To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> > 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:
<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: [clazz] Type-based or instance-based metadata? Take II
Posted by Berin Loritsch <bl...@apache.org>.
Adam Murdoch wrote:
>
>>-----Original Message-----
>>From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
>>Sent: Sunday, 27 October 2002 9:22 AM
>>To: Jakarta Commons Developers List
>>Subject: Re: [clazz] Type-based or instance-based metadata? Take II
>>
>>
>>This kind of interface is OK, and should be provided. Its essentially the
>>equivalent to BeanUtils class in [beanutils].
>>
>>However, we should focus first on getting the new class/instance model
>>defined. Users can then call a method on the model object intead
>>of a static
>>utility class.
>
>
> Definitely. This makes it easier to give the client to control things like
> which meta-info implementation to use for the model (assuming they are
> pluggable), and policies for dealing with the object graph (like, for
> example, whether it should be 'type-based' or 'instance-based').
>
> Getting rid of the statics (or having them as a convenience only) means the
> meta-info model will fit nicely into a component-oriented or IoC
> environment.
Utility classes like StringUtils and such that do not store state, or
cache instances are perfectly acceptable in all environments. There is
no way unauthorized access to information that does not belong to
unauthorized objects.
Anything that should store state or cache values should not be static.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [clazz] Type-based or instance-based metadata? Take II
Posted by Adam Murdoch <ad...@apache.org>.
> -----Original Message-----
> From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
> Sent: Sunday, 27 October 2002 9:22 AM
> To: Jakarta Commons Developers List
> Subject: Re: [clazz] Type-based or instance-based metadata? Take II
>
>
> This kind of interface is OK, and should be provided. Its essentially the
> equivalent to BeanUtils class in [beanutils].
>
> However, we should focus first on getting the new class/instance model
> defined. Users can then call a method on the model object intead
> of a static
> utility class.
Definitely. This makes it easier to give the client to control things like
which meta-info implementation to use for the model (assuming they are
pluggable), and policies for dealing with the object graph (like, for
example, whether it should be 'type-based' or 'instance-based').
Getting rid of the statics (or having them as a convenience only) means the
meta-info model will fit nicely into a component-oriented or IoC
environment.
> Stephen
>
> From: "Dmitri Plotnikov" <dm...@apache.org>
> > What if we allowed access to *any* property with *any* of these
> mechanisms:
> > scalar, indexed, mapped (and maybe parameterized)?
> >
> > Let's say we have this class:
> >
> > class Foo {
> > String getScalar()...
> > void setScalar(String)...
> > String[] getArray()...
> > void setArray(int, String)...
> > }
> >
> > Why not allow all of the following:
> >
> > ClazzUtils.get(foo, "scalar"); // returns foo
> > ClazzUtils.get(foo, "scalar", 0); // returns foo
> > ClazzUtils.get(foo, "scalar", 1); // throws exception "array out of
> bounds"
> > ClazzUtils.get(foo, "array"); // returns the array
> > ClazzUtils.get(foo, "array", 1); // returns array[1]
> > ClazzUtils.set(foo, "array", "bar"); // throws exception: "must supply
> > index"
> > ClazzUtils.get(foo, "array", "aKey"); // throws exception: "not a map"
> > ClazzUtils.get(foo, "array", "0"); // maybe returns array[0]?
> >
> > This way we don't have to know much about a property upfront in order to
> > access it. The actual figuring out is put off 'till the act of access.
> >
> > What do you think?
> >
> > - Dmitri
> >
> >
> > ----- Original Message -----
> > From: "Berin Loritsch" <bl...@apache.org>
> > To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> > Sent: Saturday, October 26, 2002 4:33 PM
> > Subject: Re: [clazz] Type-based or instance-based metadata?
> >
> >
> > > Dmitri Plotnikov wrote:
> > > > Berin,
> > > >
> > > > ----- Original Message -----
> > > > From: "Berin Loritsch" <bl...@apache.org>
> > > > To: "Jakarta Commons Developers List"
> <co...@jakarta.apache.org>
> > > > 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:
> > <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: [clazz] Type-based or instance-based metadata? Take II
Posted by Stephen Colebourne <sc...@btopenworld.com>.
This kind of interface is OK, and should be provided. Its essentially the
equivalent to BeanUtils class in [beanutils].
However, we should focus first on getting the new class/instance model
defined. Users can then call a method on the model object intead of a static
utility class.
Stephen
From: "Dmitri Plotnikov" <dm...@apache.org>
> What if we allowed access to *any* property with *any* of these
mechanisms:
> scalar, indexed, mapped (and maybe parameterized)?
>
> Let's say we have this class:
>
> class Foo {
> String getScalar()...
> void setScalar(String)...
> String[] getArray()...
> void setArray(int, String)...
> }
>
> Why not allow all of the following:
>
> ClazzUtils.get(foo, "scalar"); // returns foo
> ClazzUtils.get(foo, "scalar", 0); // returns foo
> ClazzUtils.get(foo, "scalar", 1); // throws exception "array out of
bounds"
> ClazzUtils.get(foo, "array"); // returns the array
> ClazzUtils.get(foo, "array", 1); // returns array[1]
> ClazzUtils.set(foo, "array", "bar"); // throws exception: "must supply
> index"
> ClazzUtils.get(foo, "array", "aKey"); // throws exception: "not a map"
> ClazzUtils.get(foo, "array", "0"); // maybe returns array[0]?
>
> This way we don't have to know much about a property upfront in order to
> access it. The actual figuring out is put off 'till the act of access.
>
> What do you think?
>
> - Dmitri
>
>
> ----- Original Message -----
> From: "Berin Loritsch" <bl...@apache.org>
> To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> Sent: Saturday, October 26, 2002 4:33 PM
> Subject: Re: [clazz] Type-based or instance-based metadata?
>
>
> > Dmitri Plotnikov wrote:
> > > Berin,
> > >
> > > ----- Original Message -----
> > > From: "Berin Loritsch" <bl...@apache.org>
> > > To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> > > 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:
> <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: [clazz] Type-based or instance-based metadata? Take II
Posted by Dmitri Plotnikov <dm...@apache.org>.
After some thinking the conclusion is - forget it, we cannot do
instance-based metadata. Too many lookups, no possibility of caching and
generally too much reflection work.
So, how do we resolve the issue that sometimes we don't know if a property
is indexed/mapped until runtime?
Here's a revolutionary proposal:
Let's do away with the distinction between indexed and mapped properties (as
well as parameterized attributes). Wait, before you tear up this letter,
hear me out!
What if we allowed access to *any* property with *any* of these mechanisms:
scalar, indexed, mapped (and maybe parameterized)?
Let's say we have this class:
class Foo {
String getScalar()...
void setScalar(String)...
String[] getArray()...
void setArray(int, String)...
}
Why not allow all of the following:
ClazzUtils.get(foo, "scalar"); // returns foo
ClazzUtils.get(foo, "scalar", 0); // returns foo
ClazzUtils.get(foo, "scalar", 1); // throws exception "array out of bounds"
ClazzUtils.get(foo, "array"); // returns the array
ClazzUtils.get(foo, "array", 1); // returns array[1]
ClazzUtils.set(foo, "array", "bar"); // throws exception: "must supply
index"
ClazzUtils.get(foo, "array", "aKey"); // throws exception: "not a map"
ClazzUtils.get(foo, "array", "0"); // maybe returns array[0]?
This way we don't have to know much about a property upfront in order to
access it. The actual figuring out is put off 'till the act of access.
What do you think?
- Dmitri
----- Original Message -----
From: "Berin Loritsch" <bl...@apache.org>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Saturday, October 26, 2002 4:33 PM
Subject: Re: [clazz] Type-based or instance-based metadata?
> Dmitri Plotnikov wrote:
> > Berin,
> >
> > ----- Original Message -----
> > From: "Berin Loritsch" <bl...@apache.org>
> > To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> > 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:
<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: [clazz] Type-based or instance-based metadata?
Posted by Berin Loritsch <bl...@apache.org>.
Dmitri Plotnikov wrote:
> The words MetaClass, MetaMethod etc are taken for something else. By
> definition MetaClass is a description of how Classes are represented. For
> example the class Class in the JDK is a metaclass. MetaMetaClass then is a
> description of what a MetaClass is etc. MOF (CORBA Meta Object Facility)
> goes to level 3.
Darn!
What about AttributeClass and AttributeMethod ?
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [clazz] Type-based or instance-based metadata?
Posted by Dmitri Plotnikov <dm...@apache.org>.
The words MetaClass, MetaMethod etc are taken for something else. By
definition MetaClass is a description of how Classes are represented. For
example the class Class in the JDK is a metaclass. MetaMetaClass then is a
description of what a MetaClass is etc. MOF (CORBA Meta Object Facility)
goes to level 3.
- Dmitri
----- Original Message -----
From: "Berin Loritsch" <bl...@apache.org>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Saturday, October 26, 2002 9:46 PM
Subject: Re: [clazz] Type-based or instance-based metadata?
> Adam Murdoch wrote:
> >
> >>-----Original Message-----
> >>From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
> >>Sent: Sunday, 27 October 2002 9:19 AM
> >>To: Jakarta Commons Developers List
> >>Subject: Re: [clazz] Type-based or instance-based metadata?
> >
> >
> >
> >>>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).
> >>
> >>The name of the interface could be AClass, with the implementation as
> >>AClassImpl. Not sure if this is better though. IClass and AClass
> >>feels more
> >>'right' (ie. normally I would agree with your no prefix comment Berin)
> >
> >
> > How about ClassInfo? ClassMeta? MetaClass? ClassMetaInfo?
>
>
> I like MetaClass and MetaMethod.
>
> I.e. for all Meta enabled reflection (i.e. attributes) we use the Meta
> prefix. It makes sense in this sense because we are not following the
> trap of encoding type into the name (avoiding hungarian notation
> conventions).
>
>
> --
>
> "They that give up essential liberty to obtain a little temporary safety
> deserve neither liberty nor safety."
> - Benjamin Franklin
>
>
> --
> 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: [clazz] Type-based or instance-based metadata?
Posted by Berin Loritsch <bl...@apache.org>.
Adam Murdoch wrote:
>
>>-----Original Message-----
>>From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
>>Sent: Sunday, 27 October 2002 9:19 AM
>>To: Jakarta Commons Developers List
>>Subject: Re: [clazz] Type-based or instance-based metadata?
>
>
>
>>>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).
>>
>>The name of the interface could be AClass, with the implementation as
>>AClassImpl. Not sure if this is better though. IClass and AClass
>>feels more
>>'right' (ie. normally I would agree with your no prefix comment Berin)
>
>
> How about ClassInfo? ClassMeta? MetaClass? ClassMetaInfo?
I like MetaClass and MetaMethod.
I.e. for all Meta enabled reflection (i.e. attributes) we use the Meta
prefix. It makes sense in this sense because we are not following the
trap of encoding type into the name (avoiding hungarian notation
conventions).
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [clazz] Type-based or instance-based metadata?
Posted by Adam Murdoch <ad...@apache.org>.
> -----Original Message-----
> From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
> Sent: Sunday, 27 October 2002 9:19 AM
> To: Jakarta Commons Developers List
> Subject: Re: [clazz] Type-based or instance-based metadata?
> > 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).
>
> The name of the interface could be AClass, with the implementation as
> AClassImpl. Not sure if this is better though. IClass and AClass
> feels more
> 'right' (ie. normally I would agree with your no prefix comment Berin)
How about ClassInfo? ClassMeta? MetaClass? ClassMetaInfo?
Adam
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [clazz] Type-based or instance-based metadata?
Posted by Stephen Colebourne <sc...@btopenworld.com>.
From: "Berin Loritsch" <bl...@apache.org>
> 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.
+1
> 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).
The name of the interface could be AClass, with the implementation as
AClassImpl. Not sure if this is better though. IClass and AClass feels more
'right' (ie. normally I would agree with your no prefix comment Berin)
Stephen
> 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:
<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: [clazz] Type-based or instance-based metadata?
Posted by Berin Loritsch <bl...@apache.org>.
Dmitri Plotnikov wrote:
> Berin,
>
> ----- Original Message -----
> From: "Berin Loritsch" <bl...@apache.org>
> To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [clazz] Type-based or instance-based metadata?
Posted by Dmitri Plotnikov <dm...@apache.org>.
Berin,
----- Original Message -----
From: "Berin Loritsch" <bl...@apache.org>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
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.
> >
> > Here's what I am talking about:
> >
> > Let's say we have this class:
> >
> > class Address {
> > public Object getStreet(){ return new String[]{"555", "Sole Pike"}; }
> > public Comparable getCity() { return "Chipsburg"; }
> > }
> >
> > Type-based introspection (like java.beans.Introspector) will tell us
> > that "street" is a property of type "Object" and "city" has type
> > "Comparable".
> >
> > Instance-based introspection will give us "String[]" and "String"
> > respectively.
> >
> > Question: is "street" a collection (indexed) property? From the type's
> > prospective it is not, from the instance prospective it is.
>
> But what metadata are you looking at? Your Address class is Data. What
> data about the data are you looking for? The examples you gave describe
> the Reflection API which is Type based.
>
> 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)
> 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?
>
> Stuff along those lines.
>
> --
>
> "They that give up essential liberty to obtain a little temporary safety
> deserve neither liberty nor safety."
> - Benjamin Franklin
>
>
- Dmitri
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [clazz] Type-based or instance-based metadata?
Posted by Berin Loritsch <bl...@apache.org>.
Dmitri Plotnikov wrote:
> Another dilemma we'll have to resolve is whether metadata will be
> type-based, instance-based or both.
>
> Here's what I am talking about:
>
> Let's say we have this class:
>
> class Address {
> public Object getStreet(){ return new String[]{"555", "Sole Pike"}; }
> public Comparable getCity() { return "Chipsburg"; }
> }
>
> Type-based introspection (like java.beans.Introspector) will tell us
> that "street" is a property of type "Object" and "city" has type
> "Comparable".
>
> Instance-based introspection will give us "String[]" and "String"
> respectively.
>
> Question: is "street" a collection (indexed) property? From the type's
> prospective it is not, from the instance prospective it is.
But what metadata are you looking at? Your Address class is Data. What
data about the data are you looking for? The examples you gave describe
the Reflection API which is Type based.
Most meta info that is useful is type based, not instance based.
What you are looking at is instance based reflection info. Not a more
generic meta info.
Meta info that is useful to me is things like this:
* Creation policy (pooled components, thread local components, singleton
components, etc.)
* Required components (i.e. when one component requires a component of
another type)
Stuff along those lines.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>