commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: [clazz] Some code to consider
Date Mon, 28 Oct 2002 11:46:41 GMT
>  from:    Victor Volle <>
> 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).

To be honest, I'm not sure that 'bean' implies very much these days. After all, EJBs are hardly
beans in the traditional sense.

It may be better to use Clazz and MetaClazz however. We should probably name either:
a) following reflection:

b) create out own names:

(a) might initially make more sense, but is a method bound to a specific object (a delegate)
something that should be named AMethod? Operation seems a better name. Similarly for Field
vs Property.

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

The implementation can choose to do as it wishes. It might:
a) return an unmodifiable Map - the normal case
b) return a modifiable Map - for truly dynamic beans

The advantage of returning a Map object is that you get all the Map manipulation/search objects
for free from the collections API and [collections].

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

I just didn't have time to think through that properly.

> 4. What about inner classes?

Do we care?

> 5. What about modifiers for MetaBean like
> abstract and static?


> 6. Can a MetaBean represent an interface?
> How do I differentiate? isInterface()?

Missed that one.

> 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

MetaUnit does contain a getName()!

> 9. Should it be possible to differentiate
> between "normal" operations and constructors?
> Then something like isConstructor() would be
> helpful.

Yes, probably should do this.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message