commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitri Plotnikov <>
Subject Re: [clazz] Status 2002-10-29T23:40:00Z
Date Wed, 30 Oct 2002 00:52:59 GMT
Thanks for the excellent summary.  I think it counts for an important

----- Original Message -----
From: "Stephen Colebourne" <>
To: "Jakarta Commons Developers List" <>
Sent: Tuesday, October 29, 2002 6:52 PM
Subject: [clazz] Status 2002-10-29T23:40:00Z

> Clazz has got off to a lively start!
> Clazz exists to provide a uniform low level API for classes and objects
> provides more information and flexibility than standard classes and
> The additional information includes 'meta-data' (additional data about
> classes, fields, methods etc.). The additional flexibility covers the
> expansion of what DynaBean currently does.
> At present we have 2 APIs in play, one from me in CVS, one from Dmitri
> attached to mailing list. They are fairly complementary - Dmitri has done
> much more work in the factory area. Both models agree on the fundamentals
> the meta class design, but naming is an issue (so they seem more different
> than they really are).
> The clazz API has 2 levels - meta and instance. These follow the 2 levels
> Java (Class vs Object) or Dyna (DynaClass vs DynaBean).
> Juozas has suggested that these two levels could become separate packages
> for clarity, with the instance package dependent on the meta package. This
> could provide clearer separation, but it might prevent a simple way to
> instantiate the instance package classes. (In Java Class and Object are
> in java.lang).

+1 for two packages

Actually, how about three packages: clazz (for interfaces), clazz.reflect
and clazz.instance?

> - The name Operation seems popular for a method in the clazz API. However,
> it has been used for both the meta level and instance level concept
> confusion.
> - The names Attribute, Field and Property are suggested for the field
> concept.
> - The names Clazz/Instance, Bean, Object are suggested for the
> concept.
> A resolution is needed on this topic, as it is holding up more useful
> development. One requirement is to avoid names already used by the JDK.
> solution may be to adopt one set of names (eg. Bean/Property/Operation)
> review it again later once there is more code to see if the names are

+1 for Bean/PropertyOperation

As far as the instance stuff is concerned, how about if instead of looking
for three/four entirely different words, we chose a good prefix or suffix,
e.g. BeanInstance/PropertyInstance/OperationInstance  or

> Debate also exists about whether to write specific collections
> implementations, or to provide simple methods to simulate the collection
> the clazz API. The former is more effort, but potentially much more
> powerful. One solution would be to get the simpler version running first
> add collections later.
I don't know about this one.  At this point I am completely sold on your
idea of using the Collections APIs. The idea is very powerful, I would not
put it off too much.  It may actually be the "simpler" approach. But most
importantly, it is esthetically superior. Just look at this:

// Indexed property
List list = (List)bean.getProperty("foo").get(instance);
list.set(3, "three");

// Mapped property
Map map = (Map)bean.getProperty("bar").get(instance);
map.put("one", "uno");

I think this looks *much* better than the multitude of interfaces I
proposed.  The beauty of this is that the real property value is not
necessarily a real Map.  It may be a Map, or it may be a simulation of a Map
provided by the Property.  I'd like to volunteer to write a couple of these
collections - not a big deal.

> Stephen

- Dmitri

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

View raw message