commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@btopenworld.com>
Subject Re: [clazz] Type-based or instance-based metadata? Take II
Date Sat, 26 Oct 2002 23:22:09 GMT
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" <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>


Mime
View raw message