Steve, ----- Original Message ----- From: "Steve Downey" <[EMAIL PROTECTED]> To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]> 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" <[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. 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>
