Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Date: Tue, 29 Oct 2002 19:52:59 -0500
From: Dmitri Plotnikov <dmitri@apache.org>
Subject: Re: [clazz] Status 2002-10-29T23:40:00Z
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Message-id: <05c901c27fae$b1a1e750$0200a8c0@GATEWAY>
MIME-version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
References: <00a501c27fa6$2ceca480$c72229d9@oemcomputer>

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

----- Original Message -----
From: "Stephen Colebourne" <scolebourne@btopenworld.com>
To: "Jakarta Commons Developers List" <commons-dev@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:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>