----- Original Message ----- From: "Victor Volle" <[EMAIL PROTECTED]> To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]> Sent: Sunday, October 27, 2002 10:55 AM Subject: Re: [clazz] Clazz API mock-up
> 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? Ok. I got it. > > > > 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()" I see... Ok, I like this design. Just wanted to clarify the naming: what you call Attributes are not the same as what Berin calls Attributes. Your Attributes are like my Fields. > > 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. I was talking about the "orignial" SmallTalk. Inheritance was absent from either SmallTalk-72 or SmallTalk-74. It was introduced in SmallTalk-76. <SNIP/> > 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>
