[clazz] Status 2002-10-29T23:40:00Z

[Stephen Colebourne <sc...@btopenworld.com>]

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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [clazz] Status 2002-10-29T23:40:00Z

[Dmitri Plotnikov <dm...@apache.org>]

Thanks for the excellent summary.  I think it counts for an important
milestone.

----- Original Message -----
From: "Stephen Colebourne" <sc...@btopenworld.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
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
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).

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

+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
BeanInstance/InstanceProperty/InstanceOperation?

> 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.
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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>