Dmitri > Victor, > > ----- Original Message ----- > From: "Victor Volle" <[EMAIL PROTECTED]>
[SNIP] > > 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? For a "listed" property, there might be just some method addXXX( Object value ) for an indexed property I need a method like: addXXX( int index, Object value ) So "reflection" can differentiate between both accessors. Or do I miss something here? > > > > 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. Imagine a code generator for a Data Access Layer (OR-Mapping). For each class in the hierarchy some code is generated to marshall/unmarshall the attributes. Therefore I need to know if an attribute is declared in the current class, or has been handled in the marshalling/unmarshalling code of the super class. In my current framework, I can get both: Collection/Iterator getDeclaredAttributes() Collection/Iterator getAttributes(); The implementation of getAttributes collects the list of Attributes only once (and caches them for subsequent calls). I even have a method: Collection/Iterator getAttributes( Predicate predicate ); which uses the same collection algorithm as "getAttributes()" > > 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. Oops. I am quite sure it has. But it allows to add methods on the fly. > > > 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. +1 There should be some "Loader" that has an ordered List of plugins, which creates the Model. > 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? Yup! Victor -- To unsubscribe, e-mail: <mailto:commons-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:commons-dev-help@;jakarta.apache.org>
