Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Date: Sun, 27 Oct 2002 17:18:59 -0500
From: Dmitri Plotnikov <dmitri@apache.org>
Subject: Re: [clazz] Clazz API mock-up
To: commons-dev@jakarta.apache.org
Message-id: <013301c27e06$d8ff2aa0$0200a8c0@GATEWAY>
MIME-version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
References: <012901c27e05$1165b690$0200a8c0@GATEWAY>

Steve,

----- Original Message -----
From: "Steve Downey" <steve.downey@netfolio.com>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Sent: Sunday, October 27, 2002 11:49 AM
Subject: Re: [clazz] Clazz API mock-up

> 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.
Sure, I'll work on that.

> 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.
The proposal to mix them together stems from the discussion about
instance-based metadata.

If I have a Map that has some property "foo", is it scalar, indexed or
mapped?  There is no way of knowing without looking at the value.  What this
means is that knowing an object type does not always allow us to figure out
the types its properties.

> 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.
You mean for getting/setting/adding/removing?  Sure we could encapsulate
those operations into something resembling Method, but what's the point?

> 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.
Everything maps pretty well to standard MOF, that's the point of MOF being
M3 and as complex as it is.  We are looking for a *simple* generalization of
a number of simiar programming models, not a general purpose modelling
framework.

Or are we?  If we are ready to go all the way to MOF (aka JMI), we could of
course.  However, in my personal opinion, it is much too abstract for an
average Joe like myself to find it useful for anything other than something
equally abstract.

> > > > 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.
I see the point and agree with it.

> > 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.
I was talking about SmallTalk-72 and SmallTalk-74.  I was not suggesting
that that's what we want to do - just that inheritance is not really such an
integral part of OO.

> > > 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.
Sure.  Of course they have access.  I think the issue here was my lose use
of the word "client".  Very specifically,  I was talking about a client who
simply wants to get/set property values on a bean.

- Dmitri


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>