> > 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.
+1 Operation (because an operation me be abstract a method generally not) +1 Field BTW: in XMI operations and fields are subsumed under the name "feature". > > > > 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 a) but then we need addXXX methods Anyway I would like to be able to react on some client adding a Field or Operation. > 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]. [SNIP] > > 4. What about inner classes? > > Do we care? Probably not. But can we then have a MetaModelFactory to plug in my own implementations for MetaClass and so on. (I would need it for my code generator) [SNIP] > > 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()! Oops, overlloked that. What about the name? Victor -- To unsubscribe, e-mail: <mailto:commons-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:commons-dev-help@;jakarta.apache.org>
