commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Victor Volle <>
Subject Re: [clazz] Clazz API mock-up
Date Sun, 27 Oct 2002 15:55:02 GMT

> Victor,
> ----- Original Message -----
> From: "Victor Volle" <>


> > So we need some Methods like isIndexed(), isMapped(),
> > isListed()?
> I agree.  I am not sure about isListed though. Will there be any
> difference
> between how indexed and listed properties are handled by the client?

For a "listed" property, there might be just some method 

   addXXX( Object value )

for an indexed property I need a method like:

   addXXX( int index, Object value )

So "reflection" can differentiate between both
Or do I miss something here? 

> > > 7. There are attributes associated with a Clazz and Field.
> > >
> >
> > Can I distinguish declared Fields/Methods from inherited
> > ones?
> > How do I retrieve super classes and interfaces?
> Good questions.  I'll tell you what I would personally do.  I would
> a) not have the notion of superclass for Clazz at all and flatten
> everything
> >from superclasses and interfaces,
> b) have the isAssignableFrom(Clazz) method to support client-side
> polymorphism.
> If I am *using* class Employee, does it really make any difference to me
> if
> "address" is a field of Employee or its superclass Person?
> Give me some use cases where the *client* needs to know the class
> structure
>apart from assignability.

Imagine a code generator for a Data Access Layer 
(OR-Mapping). For each class in the hierarchy some 
code is generated to marshall/unmarshall the 
attributes. Therefore I need to know if an attribute
is declared in the current class, or has been handled
in the marshalling/unmarshalling code of the super 
class. In my current framework, I can get both:
   Collection/Iterator getDeclaredAttributes()
   Collection/Iterator getAttributes();

The implementation of getAttributes collects 
the list of Attributes only once (and caches them
for subsequent calls). I even have a method:

   Collection/Iterator getAttributes( Predicate predicate );

which uses the same collection algorithm as 

> BTW, the original SmallTalk (arguably the first OO language) did not have
> the notion of inheritance.  Not that we want to go back to those times.

Oops. I am quite sure it has. But it allows to add methods
on the fly.

> > What if I have to use "mixed" plugins, i.e. for the clazz
> > at hand I have a XML specification, how do I find
> > the plugin for the super class (how do I find the XML
> > spec if there is one and how do I decide which
> > plugin to use if no XML spec can be found.)
> First of all, I believe it to be a hard requirements for [clazz] to
> address
> this issue.  However, the *client* does not need to know how these lookup
> mechanisms work.  The plugin/lookup mechanism is completely hidden from
> the
> client.


There should be some "Loader" that has an ordered 
List of plugins, which creates the Model.

> Now, to the substance of the question.  I think we should follow the idea
> introduced by the JDK Introspector: we collect data from all plugins
> willing
> to provide some and then augment that we some defaults if needed.  For
> example, let's say we have Employee which is a subclass of Person.  The
> ClazzProvider is aware of this relationship between the Classes.  Let's
> say
> there is an explicit XMLBeanInfo (see [betwixt]) available for Person, but
> not for Employee.  I am thinking, the ClazzProvider will use the
> information
> >from the XMLBeanInfo for field introduced by Person and augment it with
> defaults generated for any new fields introduced by Employee.  The client
> does not need to be aware of these manipulations.
> Does this make sense?



To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message