commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@btopenworld.com>
Subject [clazz] Status 2002-10-29T23:40:00Z
Date Tue, 29 Oct 2002 23:52:00 GMT
Clazz has got off to a lively start!

Clazz exists to provide a uniform low level API for classes and objects that
provides more information and flexibility than standard classes and objects.
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 of
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 in
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 both
in java.lang).

- 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 causing
confusion.

- The names Attribute, Field and Property are suggested for the field
concept.

- The names Clazz/Instance, Bean, Object are suggested for the class/object
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. One
solution may be to adopt one set of names (eg. Bean/Property/Operation) and
review it again later once there is more code to see if the names are right.

Debate also exists about whether to write specific collections
implementations, or to provide simple methods to simulate the collection on
the clazz API. The former is more effort, but potentially much more
powerful. One solution would be to get the simpler version running first and
add collections later.

Stephen


--
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