commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Murdoch" <adammurd...@apache.org>
Subject RE: [clazz] Type-based or instance-based metadata? Take II
Date Sun, 27 Oct 2002 00:36:35 GMT


> -----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" <dmitri@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" <bloritsch@apache.org>
> > To: "Jakarta Commons Developers List" <commons-dev@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" <bloritsch@apache.org>
> > > > To: "Jakarta Commons Developers List"
> <commons-dev@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:
> > <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> > > For additional commands, e-mail:
> > <mailto:commons-dev-help@jakarta.apache.org>
> > >
> > >
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail:
> <mailto:commons-dev-help@jakarta.apache.org>
> >
>
>
> --
> To unsubscribe, e-mail:
> <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:commons-dev-help@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message