Stephen, ----- Original Message ----- From: "Stephen Colebourne" <[EMAIL PROTECTED]> To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]> Sent: Tuesday, December 17, 2002 6:04 PM Subject: Re: [clazz] next step
> > 1. Clazz APIs and three implementations of those: > > a) Standard JavaBeans clazz loader. Recognizes properties the way > > java.beans.Introspector does, including the indexed ones. > > b) Extended Bean clazz loader. In addition to the functionality of the > > Standard loader, also > > - recognizes plural form of a property (getCustomer, > > getCustomerList, etc) > > - recognizes list (indexed) and mapped properties > > - for the list and mapped properties recognizes a number of > > additional accessors a la "addCustomer", "removeCustomer", > > "getCustomerCount" etc. > > - provides implementations of the List and Map interfaces that are > > backed by accessor methods. > > c) Mutable BeanClazz, which allows you to create Clazzes and their > > instances dynamically. > Time has constrained me from looking in detail, but this covers the basic > goals for clazz properties well ;-) Thanks. > > 2. Clazz has a new kind of feature - InstanceFactory. In the most basic > > case an InstanceFactory is an reflected constructor. In addition to the > > basic case, we also recognize as a factory a static method returning an > > instance of the target class. I was thinking that this generalization > would > > play quite well with EJBs, which have separate factory methods on the > Home. > > All these variations would be transparent to the client. > +1 > > > 3. There is a change notification mechanism. Register a > ClazzChangeListener > > with a Clazz and you will get notifications when the clazz changes: a > > property, operation or factory is added or removed. > +1 > > > > 1. Attributes. There is a placeholder method on ClazzElement: > > getAttribute(String name), however it is currently unimplemented. I think > > we need to better understand our relationship with the [attribute] project > > before we finalize these APIs. > I see [clazz] depending on [attributes] for the implementation of > attributes. However, [clazz] users might also want to implement their own > attribute mechanism independent of [attributes], so a light conversion layer > of some kind is probably needed. I got that. The issue is really more organizational than technical. I would like our [clazz] attributes to be conceptually an functionally aligned with those in [attribute]. I'll try to get somebody from the [attributes] team engaged. > > 2. Delegators. If my understanding of Delegators is correct, we need a > > method like this: > > > > clazz.addDeclaredOperation(ClazzOperation delegator) > > > > These delegators will be seen as regular, method-based operations by the > > client. Is this correct? Is there more to them? Do they need to be > > designated as "delegators"? > A ClazzOperation in reflection terms is a Method object, however it might > alternatively be implemented as a Jelly script or Velocity transformation or > .... Basically anywhere where there is processing. eg. > clazzOp.invoke(object, params) > > An Operation is the delegate. It is the ClazzOperation, plus a reference to > the bean itself. eg. > op.invoke(params) Ok.That's pretty much the way I wrote them. However the questions remain the same: is there anything special about delegators from the _client_'s side? > > 3. Interfaces. I am not sure what the use case would be for interfaces in > > the Clazz world (I guess they would have to be called "interfazes". We > can > > always inquire like this: > > > > MyInteface.class.isAssignableFrom(clazz.getInstanceClass()) > > > > Does this address the requirement or we need actual Interfaze metadata for > > something? > I would avoid interfaces for the moment. We don't have a use case, and they > add complexity. If [clazz] succeeds then we can add them later. I am with you on this one. > > 4. Exception declarations on operations. Once again, I am not sure what > the > > purpose of that would be. When you call clazzOperation.invoke(...), it > may > > throw a RuntimeException, which can be examined dynamically, but I am not > > convinced we need any metadata on it. > Agreed, extra metadata here is not useful. So be it. > > 5. Modifiers. Currently, everything introspected is based on public > methods > > of the target class. What are some use cases for modifiers on > > ClazzProperties and ClazzOperations? > In the Joda system, private methods can be introspected as this allows tools > like XML readers to set values, but not ordinary program code. This doesn't > require that ClazzProperties and ClazzOperations themselves have modifiers. > We are trying to enable access to the properties/operations, not provide > information on things that aren't accessible. > > One thing we need to be careful of is performance. As I have found at work, > an object model that creates too many objects will scale badly. But we > should optimise once the basic design is right and working. Premature > optimisation is Bad ;-) Exactly. I am well aware of this performance consideration. Sun claims that in the new JDKs object allocation is virtually free. I have trouble believing that. Thank you, > > Stephen > - Dmitri -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
