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 Mon, 28 Oct 2002 02:11:26 GMT
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" <steve.downey@netfolio.com>
To: "Jakarta Commons Developers List" <commons-dev@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" <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