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>
Message-ID: <002401c27db0$9545f060$352929d9@oemcomputer>
From: "Stephen Colebourne" <scolebourne@btopenworld.com>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
References: <5.1.0.14.0.20021027112720.042f7e90@pop.scioworks.com>
Subject: Re: [clazz] Scope?
Date: Sun, 27 Oct 2002 12:01:28 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Scope, hmm, yes its a little tricky to define, which has been a concern of
mine too.

Use case 1:
Provide standardised access to Beans - a replacement to Introspector.
This covers simple, array, List and Map properties.
It also covers non-standard naming conventions, eg. other than 'get' and
'set'.

Use case 2:
Property may not be a simple method call on the object.
This enables a Map of data on the Bean to be treated as real properties.

Use case 3:
Handle non-standard Bean types.
This covers the ground that DynaBean covers. Beans that aren't written as a
new class, but instantiated instead as instances of the same class.

Use case 4:
To be able to store attributes (meta-data) against classes.
Initially conceived as just a store used at runtime, has developed into the
ability to pickup values from XML files, and generated source/byte code.


#1, #2 and #3 are the key ones for tools such as Betwixt, Jexl, JXPath and
so on to be able to locate what properties there are on an object in a
pluggable way.

#4 just seems to drop out as an additional benefit. It wasn't my immediate
goal.

There is possibly a question of whether there is one or two projects here. I
would like to keep it as one for the moment. If the metadata stuff becomes a
big thing then the bean stuff breaks out at that point.

Stephen

----- Original Message -----
From: "John Yu" <john@scioworks.com>
> I've been following the threads on [clazz]. There're many intriguing ideas
> floating around. However, it is still unclear to me what/how the package
> tries to achieve in concrete terms. What's described in "proposal.html" is
> pretty abstract.
>
> (But I understand the project is still at an "exploring" stage and various
> ideas are been explored.)
>
> It seems to me [clazz] tries to deal with the following areas:
>
> WHATS:
>     * Implement a clone of delegators (aka bound method references).
>     * Implement some doclet-like meta-attributes for "annotating" Java
> classes; these meta-attributes are sort of orthogonal to the object model.
>     * Generalize java.lang.reflect.* and java.beans.*; this seems to be a
> followup work of BeanUtils.
>     * Provide a generic metaclass framework capable of altering class
> definitions at runtime. Very ambitious!
> (Of course, a metaclass framework is a superset of all. If this can be
> done, all the other will fall into places.)
>
> HOWS:
>     * Source code pre-processing and generation
>     * Byte-code generation via BCEL
>     * Dynamic Proxy
> Have I missed anything? (Avalon has been mentioned many times in the
> threads. I'm not familiar with Alavon. I may have misunderstood stuff.)
>
> If a generic metaclass framework is the goal, I'd suggest to take a look
of
> some existing meta-object protocols (MOP) as they have strong theoretical
> foundations. Two MOPs come to my minds are IBM's SOM C++ metaclass
> framework
>
(http://www2.parc.com/csl/groups/sda/projects/reflection96/docs/forman/forma
n.pdf)
> and OpenJava (http://www.csg.is.titech.ac.jp/openjava/).
>
> Anyway, back to my question: Do we need to clarify the scope?
>
> --
> John Yu
>
>
> --
> To unsubscribe, e-mail:
<mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:commons-dev-help@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>