On Sunday 27 October 2002 10:38 am, Dmitri Plotnikov wrote:
> 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
> > > 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?
>
I would think so. A list is not fixed in size. So pretending that List ==
Array is bad form. I think there needs to be a way of getting and dealing
with an iterator for collection properties.
I don't particularly care for mixing different field types in the same
interface. It makes the interface clunky and error-prone, in my opinion. I
think PropertyDescriptor and IndexedPropertyDescriptor make sense. I'd just
like to see something like CollectionPropertyDescriptor.
Some of this seems to be straying into 'fix the language' type issues. For
example, I can see why we might not be able to return an actual 'Method'
object, I don't see why we can't return something that act like it.
Java's Introspection mechanism maps pretty well to a standard MOF. I don't
think the extended mechanism we're devising here needs to take a radically
different approach.
> > > 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.
>
When you're working with the classes as classes, not as instances. Let's say
I'm building a modeling tool. I'd want to show the attributes of the
superclass in the superclass, not in the subclass. However, I think that's a
little distant from our main use cases.
> 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.
>
Smalltalk has inheritance. It doesn't even require that all objects be derived
from Object. What it does allow is any message to be sent to any object, and
you might get back message not understood. Strong runtime typing, weak
compile time typing.
> > 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.
>
Rather than hidden, I'd like it to be ignoreable. That is, if the client for
some reason needs access to the mechanisms, it can get access. Plug in
different ones, or override the ones present. For example, there are likely
to be several possible sources for metadata. Doclets, XML, handcrafted
classes, JNDI, system properties, black magick, etc. You may want to ignore
one or more of them.
Most clients won't need it. Those that do, should have access.
--
-SMD
--
To unsubscribe, e-mail: <mailto:commons-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@;jakarta.apache.org>
