commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitri Plotnikov <dmi...@apache.org>
Subject Re: [clazz] Type-based or instance-based metadata? Take II
Date Sat, 26 Oct 2002 22:20:53 GMT
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" <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>


Mime
View raw message