You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Stephen Colebourne <sc...@btopenworld.com> on 2002/10/27 23:49:29 UTC
[clazz] Some code to consider
I have checked into the [clazz] sandbox some classes. They represent the
basic ideas of where I was headed.
They include a meta model
MetaBean
MetaProperty
MetaOperation
all extending MetaUnit
and an instance model
Bean
Property
Operation
all extending Unit
All can have 'meta data', as an arbitrary Map of 'Attributes'.
Delegated properties and methods are supported (Property and Operation).
Comments welcome.
Stephen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [clazz] Some code to consider
Posted by Juozas Baliuka <ba...@centras.lt>.
I thin it needs some separation "model" can be used in tools like compiler,
doclet,
source code generator, debuger, editor ... . Default implementation can be
based on reflection (packages,classes, methods, costructors, fields ... ) .
Framework can be in separate paskage ( properties, events, delegates ... ).
I think it will be more simple to understand and reuse, it is like java's
reflect/beans.
> This adds to the complexity of the API. What advantages do we get in
return?
> (Certainly naming would be easier ;-)
>
> Stephen
>
> ----- Original Message -----
> From: "Juozas Baliuka" <ba...@centras.lt>
> To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> Sent: Monday, October 28, 2002 7:27 PM
> Subject: Re: [clazz] Some code to consider
>
>
> > Hi,
> > I want to add all "features" to Meta* interfaces, I think this model
must
> > not to "reduce" jdk reflection.
> > I propose two packages :
> > 1) "xreflect" package (we can use naming like java.lang.reflect.* +
> > "attributes").
> > 2) "xbeans" package for "beans" like framework. ("delegate" can live
> here)
> >
> > "tools" like "xdoclets" is subject for next component, but we need some
> API
> > in [clazz] to plug implementations.
> >
> >
> >
> >
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [clazz] Some code to consider
Posted by Stephen Colebourne <sc...@btopenworld.com>.
This adds to the complexity of the API. What advantages do we get in return?
(Certainly naming would be easier ;-)
Stephen
----- Original Message -----
From: "Juozas Baliuka" <ba...@centras.lt>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Monday, October 28, 2002 7:27 PM
Subject: Re: [clazz] Some code to consider
> Hi,
> I want to add all "features" to Meta* interfaces, I think this model must
> not to "reduce" jdk reflection.
> I propose two packages :
> 1) "xreflect" package (we can use naming like java.lang.reflect.* +
> "attributes").
> 2) "xbeans" package for "beans" like framework. ("delegate" can live
here)
>
> "tools" like "xdoclets" is subject for next component, but we need some
API
> in [clazz] to plug implementations.
>
>
>
>
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [clazz] Some code to consider
Posted by Juozas Baliuka <ba...@centras.lt>.
Hi,
I want to add all "features" to Meta* interfaces, I think this model must
not to "reduce" jdk reflection.
I propose two packages :
1) "xreflect" package (we can use naming like java.lang.reflect.* +
"attributes").
2) "xbeans" package for "beans" like framework. ("delegate" can live here)
"tools" like "xdoclets" is subject for next component, but we need some API
in [clazz] to plug implementations.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [clazz] Some code to consider
Posted by Victor Volle <vi...@gmxpro.net>.
Stephen,
good idea to have something concrete.
> I have checked into the [clazz] sandbox some classes. They represent the
> basic ideas of where I was headed.
>
> They include a meta model
> MetaBean
> MetaProperty
> MetaOperation
> all extending MetaUnit
1. I do not like the name MetaBean, I would prefer Clazz or
MetaClass, because "Bean" implies that I have to have
getters and setters. I know that this is an important use
case, but sometimes I am only interested in the
operations (interfaces etc.).
I do not like the name MetaProperty for the same reason.
I would prefer Field (Berin) or Attribute (UML).
The following is a list of differences to the model
I have in mind (already implemented for some stuff
i am working on):
2. In the method MetaBean#getMetaPropertyMap you
return the map of properties, I am always afraid
giving a way internal collections, because a client
can modify them directly. I always prefer having
adders and removers for elements, so the class
(MetaBean) can keep track of its elements and
do some bookkeeping.
Or do you intend to always create a copy?
3. I still would like to be able to differentiaite
between properties/operations declared
in/for the current MetaBean and
properties/operations declared in super classes
and interfaces.
4. What about inner classes?
5. What about modifiers for MetaBean like
abstract and static?
6. Can a MetaBean represent an interface?
How do I differentiate? isInterface()?
7. What about having a getName() operation
in MetaUnit? (why "unit"? what about
MetaModelElement? "unit" sounds wrong
for me, but I can not explain why).
In MetaBean this could return
Package+ShortClassName
8. MetaOperation: modifiers?
9. Should it be possible to differentiate
between "normal" operations and constructors?
Then something like isConstructor() would be
helpful.
Victor
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [clazz] Some code to consider
Posted by Juozas Baliuka <ba...@centras.lt>.
I prefer "Feature" with some sufix like "Descriptor"
public interface Unit {
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
/**
* Get the Map of string to string attributes.
*
* @return string/string attribute Map
*/
I think we need to remove this method
Map getAttributeMap();
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
/**
* Get the count of attributes.
* This should be checked rather than getAttributes().size() to
* allow for lazily instantiated attribute maps.
*
* @return the number of attributes
*/
int getAttributeCount();
/**
* Get an attribute by key.
*
* @param key the key to get
* @return attribute value by key, null if not found
*/
I prefer "Object" as return value
String getAttribute(String key);
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
/**
* Set an attribute key and value.
*
* @param key the key to set
* @param value the value to set
*/
"Object" for attribute type
void setAttribute(String key, String value);
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
I want to add this:
List getAttributeNames();
}
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>