Victor, ----- Original Message ----- From: "Victor Volle" <[EMAIL PROTECTED]> To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Sunday, October 27, 2002 9:02 AM Subject: Re: [clazz] Clazz API mock-up
> > Please check out the two attached classes: Clazz and Field. These are > > What about Method? Of course it will be there. I just wanted to start getting feedback as early as possible, because there are so many interested parties and so many different approaches to the problem. I think method is much less controversial than field. > > client > > APIs only. Nothing is said about where the metadata is coming from - > > that's > > to come later. > > > > Here are some notes on the design of these two classes: > > > > 1. Clazz is a metadescription of a generalized bean (JDK bean, "modern" > > bean, DynaBean, Map, EJB etc). > > > > 2. In some cases there is more than one Clazz that can describe a > > particular > > object. For example, the same object can be described as a standard bean > > as > > well as a "modern" bean. Therefore I have introduced the notion of a > > "model" identified by a URI. I am thinking the URI itself might map to a > > verbal description of the model. > > > > 3. Clazz has a newInstance() method that is responsible for object > > allocation. > > > > 4. You do not get a list of Field objects from a Clazz. Instead, you get > > a > > list of field names and then can acquire a Field object for an individual > > field. The reason is that allocation of Field objects may involve > > multiple > > plugins and therefore be costly. Also, in the case of a Map, we would > > effectively be recreating the map with the Field objects. > > > > +1 > > > 5. Field hides the mechanisms of actual value extraction/manipulation. > > You > > don't get any "readMethods", "writeMethods" etc. You simply delegate the > > value manipulations to the Field object. > > > > +1 > > > 6. Field is scalar, indexed and mapped at the same time and has all > > corresponding APIs. If you use the wrong APIs on a field, it will just > > throw an exception. > > > > So we need some Methods like isIndexed(), isMapped(), > isListed()? I agree. I am not sure about isListed though. Will there be any difference between how indexed and listed properties are handled by the client? > > 7. There are attributes associated with a Clazz and Field. > > > > Can I distinguish declared Fields/Methods from inherited > ones? > How do I retrieve super classes and interfaces? Good questions. I'll tell you what I would personally do. I would a) not have the notion of superclass for Clazz at all and flatten everything from superclasses and interfaces, b) have the isAssignableFrom(Clazz) method to support client-side polymorphism. If I am *using* class Employee, does it really make any difference to me if "address" is a field of Employee or its superclass Person? Give me some use cases where the *client* needs to know the class structure apart from assignability. BTW, the original SmallTalk (arguably the first OO language) did not have the notion of inheritance. Not that we want to go back to those times. > What if I have to use "mixed" plugins, i.e. for the clazz > at hand I have a XML specification, how do I find > the plugin for the super class (how do I find the XML > spec if there is one and how do I decide which > plugin to use if no XML spec can be found.) First of all, I believe it to be a hard requirements for [clazz] to address this issue. However, the *client* does not need to know how these lookup mechanisms work. The plugin/lookup mechanism is completely hidden from the client. Now, to the substance of the question. I think we should follow the idea introduced by the JDK Introspector: we collect data from all plugins willing to provide some and then augment that we some defaults if needed. For example, let's say we have Employee which is a subclass of Person. The ClazzProvider is aware of this relationship between the Classes. Let's say there is an explicit XMLBeanInfo (see [betwixt]) available for Person, but not for Employee. I am thinking, the ClazzProvider will use the information from the XMLBeanInfo for field introduced by Person and augment it with defaults generated for any new fields introduced by Employee. The client does not need to be aware of these manipulations. Does this make sense? > Victor - Dmitri -- To unsubscribe, e-mail: <mailto:commons-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:commons-dev-help@;jakarta.apache.org>
