commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Downey <steve.dow...@netfolio.com>
Subject Re: [clazz] Clazz API mock-up
Date Sun, 27 Oct 2002 16:49:04 GMT
On Sunday 27 October 2002 10:38 am, Dmitri Plotnikov wrote:
> Victor,
>
> ----- Original Message -----
> From: "Victor Volle" <victor.volle@gmxpro.net>
> To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
> Cc: <commons-dev@jakarta.apache.org>
> 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>


Mime
View raw message