> from: Victor Volle <[EMAIL PROTECTED]> > 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: MetaClass/MetaField/MetaMethod AClass/AField/AMethod b) create out own names: MetaClazz/MetaProperty/MetaOperation Clazz/Property/Operation (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? MetaUnit.getModifiers() > 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. Stephen -- To unsubscribe, e-mail: <mailto:commons-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:commons-dev-help@;jakarta.apache.org>
