You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Dmitri Plotnikov <dm...@apache.org> on 2002/10/27 14:34:26 UTC
[clazz] Clazz API mock-up
Please check out the two attached classes: Clazz and Field. These are client
APIs only. Nothing is said about where the metadata is coming from - that's
to come later.
Here are some notes on the design of these two classes:
1. Clazz is a metadescription of a generalized bean (JDK bean, "modern"
bean, DynaBean, Map, EJB etc).
2. In some cases there is more than one Clazz that can describe a particular
object. For example, the same object can be described as a standard bean as
well as a "modern" bean. Therefore I have introduced the notion of a
"model" identified by a URI. I am thinking the URI itself might map to a
verbal description of the model.
3. Clazz has a newInstance() method that is responsible for object
allocation.
4. You do not get a list of Field objects from a Clazz. Instead, you get a
list of field names and then can acquire a Field object for an individual
field. The reason is that allocation of Field objects may involve multiple
plugins and therefore be costly. Also, in the case of a Map, we would
effectively be recreating the map with the Field objects.
5. Field hides the mechanisms of actual value extraction/manipulation. You
don't get any "readMethods", "writeMethods" etc. You simply delegate the
value manipulations to the Field object.
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.
7. There are attributes associated with a Clazz and Field.
Does any of this make sense?
- Dmitri
Re: [clazz] Clazz API mock-up
Posted by Berin Loritsch <bl...@apache.org>.
Dmitri Plotnikov wrote:
> Berin,
>
> ----- Original Message -----
> From: "Berin Loritsch" <bl...@apache.org>
> To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> Sent: Sunday, October 27, 2002 8:05 PM
> Subject: Re: [clazz] Clazz API mock-up
>
>
>
>>Dmitri Plotnikov wrote:
>>
>>>Please check out the two attached classes: Clazz and Field. These are
>>
> client
>
>>>APIs only. Nothing is said about where the metadata is coming from -
>>
> that's
>
>>>to come later.
>>>
>>>Here are some notes on the design of these two classes:
>>>
>>>1. Clazz is a metadescription of a generalized bean (JDK bean, "modern"
>>>bean, DynaBean, Map, EJB etc).
>>>
>>>2. In some cases there is more than one Clazz that can describe a
>>
> particular
>
>>>object. For example, the same object can be described as a standard bean
>>
> as
>
>>>well as a "modern" bean. Therefore I have introduced the notion of a
>>>"model" identified by a URI. I am thinking the URI itself might map to
>>
> a
>
>>>verbal description of the model.
>>>
>>>3. Clazz has a newInstance() method that is responsible for object
>>>allocation.
>>
>>I looked at the API stuff. I think there is an awful lot of extra stuff.
>>KISS (Keep It Simple, Stupid).
>
> I think the expression is actually "Keep It Simple and Stupid", otherwise it
> might sound like you are calling me stupid, which of course you never would.
:) That's the way my mom taught it to me. But know I am not calling you
stupid. Another variation is "Keep It Short and Simple"
>
> Do you really mean that there is an "awful" lot of extra stuff or you mean
> that the stuff is not very well compartmentalized into little Method
> objects? I'll buy that for a dollar.
There is some extra stuff. It just feels cluttered. But proper
compartmentalization would help.
>
>>Let's follow the java.lang.reflect.* as much as possible. Provide a
>>getClass() method to get the original class. Provide a getMethod() for
>>the AttributeMethod from the clazz. That sort of thing.
>
> Could you elaborate a little bit? Could you give some examples of APIs
> along with examples of how you envision them being used? I am especially
> interested in the dynamic case where there are no concrete classes, just
> data and metadata constructed at runtime.
>
> What would I use getClass() for? Why not call object.getClass() directly?
It's another way of getting it. What if you are passing the meta object
directly? Without the original reference there is no other way of getting
the Class object.
>
> What is the benefit of encapsulating access into a Method object? At this
> early stage of design work the reason has to be more than pure esthetics.
I am thinking about symetry with java.lang.Reflet.*
I am also looking for a way of determining from the method implemented by
a component and defined by an interface what the attributes are. For example,
if I want to generate JMX MBeans based on an interface, I need to find the
attributes for each of the methods so that the MBean has the proper description
and every thing.
Lets look at two examples (both with javadoc style attribute declaration):
/**
* @avalon-requires:org.apache.avalon.excalibur.datasource.DataSourceComponent
*/
void service( ServiceManager manager );
/**
* @mx-description: Retrieve a resource from a remote location
* @mx-method
* @mx-parameter:java.lang.String
* @mx-parameter:java.net.URL
* @mx-return:java.io.InputStream
*/
InputStream getResourceName( String key, URL location );
In the first example, the attribute is used by the container to ensure that
the DataSource pool is provided. In the second example, the code to generate
MBeans will use the description and the fact that the mx-method attribute
exists.
To be even more powerful, we need a special classloader that can query all
attributes and return the appropriate AttributeMethod/AttributeClass associated
with the requested attribute.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [clazz] Clazz API mock-up
Posted by Dmitri Plotnikov <dm...@apache.org>.
Berin,
----- Original Message -----
From: "Berin Loritsch" <bl...@apache.org>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Sunday, October 27, 2002 8:05 PM
Subject: Re: [clazz] Clazz API mock-up
> Dmitri Plotnikov wrote:
> > Please check out the two attached classes: Clazz and Field. These are
client
> > APIs only. Nothing is said about where the metadata is coming from -
that's
> > to come later.
> >
> > Here are some notes on the design of these two classes:
> >
> > 1. Clazz is a metadescription of a generalized bean (JDK bean, "modern"
> > bean, DynaBean, Map, EJB etc).
> >
> > 2. In some cases there is more than one Clazz that can describe a
particular
> > object. For example, the same object can be described as a standard bean
as
> > well as a "modern" bean. Therefore I have introduced the notion of a
> > "model" identified by a URI. I am thinking the URI itself might map to
a
> > verbal description of the model.
> >
> > 3. Clazz has a newInstance() method that is responsible for object
> > allocation.
>
> I looked at the API stuff. I think there is an awful lot of extra stuff.
> KISS (Keep It Simple, Stupid).
I think the expression is actually "Keep It Simple and Stupid", otherwise it
might sound like you are calling me stupid, which of course you never would.
Do you really mean that there is an "awful" lot of extra stuff or you mean
that the stuff is not very well compartmentalized into little Method
objects? I'll buy that for a dollar.
> Let's follow the java.lang.reflect.* as much as possible. Provide a
> getClass() method to get the original class. Provide a getMethod() for
> the AttributeMethod from the clazz. That sort of thing.
Could you elaborate a little bit? Could you give some examples of APIs
along with examples of how you envision them being used? I am especially
interested in the dynamic case where there are no concrete classes, just
data and metadata constructed at runtime.
What would I use getClass() for? Why not call object.getClass() directly?
What is the benefit of encapsulating access into a Method object? At this
early stage of design work the reason has to be more than pure esthetics.
- Dmitri
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [clazz] Clazz API mock-up
Posted by Berin Loritsch <bl...@apache.org>.
Dmitri Plotnikov wrote:
> Please check out the two attached classes: Clazz and Field. These are client
> APIs only. Nothing is said about where the metadata is coming from - that's
> to come later.
>
> Here are some notes on the design of these two classes:
>
> 1. Clazz is a metadescription of a generalized bean (JDK bean, "modern"
> bean, DynaBean, Map, EJB etc).
>
> 2. In some cases there is more than one Clazz that can describe a particular
> object. For example, the same object can be described as a standard bean as
> well as a "modern" bean. Therefore I have introduced the notion of a
> "model" identified by a URI. I am thinking the URI itself might map to a
> verbal description of the model.
>
> 3. Clazz has a newInstance() method that is responsible for object
> allocation.
I looked at the API stuff. I think there is an awful lot of extra stuff.
KISS (Keep It Simple, Stupid).
Let's follow the java.lang.reflect.* as much as possible. Provide a
getClass() method to get the original class. Provide a getMethod() for
the AttributeMethod from the clazz. That sort of thing.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [clazz] Clazz API mock-up
Posted by Berin Loritsch <bl...@apache.org>.
Victor Volle wrote:
> Berin
>
>
>>Victor Volle wrote:
>>
>>>>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.
>>>
>>>
>>>Yes, I think so. Imagine a class "Foo" with an instance variable
>>>"bar". In the MetaModel the MetaClass Foo would have an
>>>(Meta)Attribute that has the name "bar". This "bar" can have
>>>properties/extensions/attributes.
>>>
>>>What do you prefer?
>>
>>Be clear in your definitions.
>
>
> I thought I was :-(
> (sorry, I am no native speaker)
All I am saying is that we don't want to overload terms. Use separate
terms for seperate concepts.
>
>
>
>>Attributes have a name and parameters. They are not representing anything
>>concrete in the class already.
>
>
> Sorry, I do not get it. I really think that we might mean different
> things by the name of "attribute".
> Can your "attributes" be attributes of Classes only and represent
> instance variables?
> Or:
> Are your "attributes" attributes of any
> MetaModelElement like Classes, Methods/Operations and
> Attributes/Fields. Then your "attribute" is something like
> C# attributes? Adding some semantics to a model element.
> And you would call my "attribute" a "field"?
My attributes are like the C# attributes. That is the whole point of it.
I would call your attribute a Field, in the Java sense of it.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [clazz] Clazz API mock-up
Posted by Victor Volle <vi...@gmxpro.net>.
Berin
> Victor Volle wrote:
> >>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.
> >
> >
> > Yes, I think so. Imagine a class "Foo" with an instance variable
> > "bar". In the MetaModel the MetaClass Foo would have an
> > (Meta)Attribute that has the name "bar". This "bar" can have
> > properties/extensions/attributes.
> >
> > What do you prefer?
>
> Be clear in your definitions.
I thought I was :-(
(sorry, I am no native speaker)
> Attributes have a name and parameters. They are not representing anything
> concrete in the class already.
Sorry, I do not get it. I really think that we might mean different
things by the name of "attribute".
Can your "attributes" be attributes of Classes only and represent
instance variables?
Or:
Are your "attributes" attributes of any
MetaModelElement like Classes, Methods/Operations and
Attributes/Fields. Then your "attribute" is something like
C# attributes? Adding some semantics to a model element.
And you would call my "attribute" a "field"?
Victor
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [clazz] Clazz API mock-up
Posted by Berin Loritsch <bl...@apache.org>.
Victor Volle wrote:
>>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.
>
>
> Yes, I think so. Imagine a class "Foo" with an instance variable
> "bar". In the MetaModel the MetaClass Foo would have an
> (Meta)Attribute that has the name "bar". This "bar" can have
> properties/extensions/attributes.
>
> What do you prefer?
Be clear in your definitions.
Attributes have a name and parameters. They are not representing anything
concrete in the class already.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [clazz] Clazz API mock-up
Posted by Dmitri Plotnikov <dm...@apache.org>.
Victor,
----- Original Message -----
From: "Victor Volle" <vi...@gmxpro.net>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Sunday, October 27, 2002 11:29 AM
Subject: Re: [clazz] Clazz API mock-up
> > 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.
>
> Yes, I think so. Imagine a class "Foo" with an instance variable
> "bar". In the MetaModel the MetaClass Foo would have an
> (Meta)Attribute that has the name "bar". This "bar" can have
> properties/extensions/attributes.
>
> What do you prefer?
My personal preference would be "Field" because of its similarity to
java.lang.reflect.Field.
<snip/>
- Dmitri
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [clazz] Clazz API mock-up
Posted by Victor Volle <vi...@gmxpro.net>.
> 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.
Yes, I think so. Imagine a class "Foo" with an instance variable
"bar". In the MetaModel the MetaClass Foo would have an
(Meta)Attribute that has the name "bar". This "bar" can have
properties/extensions/attributes.
What do you prefer?
> > > 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.
Oh, I did not know that. I just know Smalltalk80.
(I have written a minimal smalltalk system
as a project in university).
Victor
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [clazz] Clazz API mock-up
Posted by Dmitri Plotnikov <dm...@apache.org>.
----- Original Message -----
From: "Victor Volle" <vi...@gmxpro.net>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Sunday, October 27, 2002 10:55 AM
Subject: Re: [clazz] Clazz API mock-up
> Dmitri
>
> > Victor,
> >
> > ----- Original Message -----
> > From: "Victor Volle" <vi...@gmxpro.net>
>
> [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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [clazz] Clazz API mock-up
Posted by Victor Volle <vi...@gmxpro.net>.
Dmitri
> Victor,
>
> ----- Original Message -----
> From: "Victor Volle" <vi...@gmxpro.net>
[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?
>
> > > 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()"
>
> 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.
>
> > 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.
+1
There should be some "Loader" that has an ordered
List of plugins, which creates the Model.
> Now, to the substance of the question. I think we should follow the idea
> introduced by the JDK Introspector: we collect data from all plugins
> willing
> to provide some and then augment that we some defaults if needed. For
> example, let's say we have Employee which is a subclass of Person. The
> ClazzProvider is aware of this relationship between the Classes. Let's
> say
> there is an explicit XMLBeanInfo (see [betwixt]) available for Person, but
> not for Employee. I am thinking, the ClazzProvider will use the
> information
> >from the XMLBeanInfo for field introduced by Person and augment it with
> defaults generated for any new fields introduced by Employee. The client
> does not need to be aware of these manipulations.
>
> Does this make sense?
Yup!
Victor
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [clazz] Clazz API mock-up
Posted by Steve Downey <st...@netfolio.com>.
On Sunday 27 October 2002 10:38 am, Dmitri Plotnikov wrote:
> Victor,
>
> ----- Original Message -----
> From: "Victor Volle" <vi...@gmxpro.net>
> To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> Cc: <co...@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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [clazz] Clazz API mock-up
Posted by Dmitri Plotnikov <dm...@apache.org>.
Victor,
----- Original Message -----
From: "Victor Volle" <vi...@gmxpro.net>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Cc: <co...@jakarta.apache.org>
Sent: Sunday, October 27, 2002 9:02 AM
Subject: Re: [clazz] Clazz API mock-up
> > Please check out the two attached classes: Clazz and Field. These are
>
> What about Method?
Of course it will be there. I just wanted to start getting feedback as
early as possible, because there are so many interested parties and so many
different approaches to the problem. I think method is much less
controversial than field.
> > client
> > APIs only. Nothing is said about where the metadata is coming from -
> > that's
> > to come later.
> >
> > Here are some notes on the design of these two classes:
> >
> > 1. Clazz is a metadescription of a generalized bean (JDK bean, "modern"
> > bean, DynaBean, Map, EJB etc).
> >
> > 2. In some cases there is more than one Clazz that can describe a
> > particular
> > object. For example, the same object can be described as a standard bean
> > as
> > well as a "modern" bean. Therefore I have introduced the notion of a
> > "model" identified by a URI. I am thinking the URI itself might map to
a
> > verbal description of the model.
> >
> > 3. Clazz has a newInstance() method that is responsible for object
> > allocation.
> >
> > 4. You do not get a list of Field objects from a Clazz. Instead, you
get
> > a
> > list of field names and then can acquire a Field object for an
individual
> > field. The reason is that allocation of Field objects may involve
> > multiple
> > plugins and therefore be costly. Also, in the case of a Map, we would
> > effectively be recreating the map with the Field objects.
> >
>
> +1
>
> > 5. Field hides the mechanisms of actual value extraction/manipulation.
> > You
> > don't get any "readMethods", "writeMethods" etc. You simply delegate
the
> > value manipulations to the Field object.
> >
>
> +1
>
> > 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?
> > 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.
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.
> 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.
Now, to the substance of the question. I think we should follow the idea
introduced by the JDK Introspector: we collect data from all plugins willing
to provide some and then augment that we some defaults if needed. For
example, let's say we have Employee which is a subclass of Person. The
ClazzProvider is aware of this relationship between the Classes. Let's say
there is an explicit XMLBeanInfo (see [betwixt]) available for Person, but
not for Employee. I am thinking, the ClazzProvider will use the information
from the XMLBeanInfo for field introduced by Person and augment it with
defaults generated for any new fields introduced by Employee. The client
does not need to be aware of these manipulations.
Does this make sense?
> Victor
- Dmitri
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Commons fileupload build fails
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Sun, 27 Oct 2002, Rob Leland wrote:
> Date: Sun, 27 Oct 2002 12:44:42 -0500
> From: Rob Leland <rl...@apache.org>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: Jakarta Commons Developers List <co...@jakarta.apache.org>,
> sullis@apache.org
> Subject: Commons fileupload build fails
>
> The commons fileupload nightly build for Oct 27, Sunday Morning
> failed. The archive files are missing.
> I also wasn't able to build from the CVS.
>
It throws the following compile error for me:
.../jakarta-commons/fileupload/src/test/org/apache/commons/fileupload/MultipartStreamTest.java:67: TestCase() is not public in junit.framework.TextCase: cannot be accessed from outside package
It looks like the Maven-generated "get-deps" target correctly graps JUnit
3.8.1 (I normally use 3.7) -- could a version difference here cause this?
> Luckly the sandbox version does build.
>
> -Rob
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Commons fileupload build fails
Posted by Rob Leland <rl...@apache.org>.
The commons fileupload nightly build for Oct 27, Sunday Morning
failed. The archive files are missing.
I also wasn't able to build from the CVS.
Luckly the sandbox version does build.
-Rob
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [clazz] Clazz API mock-up
Posted by Victor Volle <vi...@gmxpro.net>.
> Please check out the two attached classes: Clazz and Field. These are
What about Method?
> client
> APIs only. Nothing is said about where the metadata is coming from -
> that's
> to come later.
>
> Here are some notes on the design of these two classes:
>
> 1. Clazz is a metadescription of a generalized bean (JDK bean, "modern"
> bean, DynaBean, Map, EJB etc).
>
> 2. In some cases there is more than one Clazz that can describe a
> particular
> object. For example, the same object can be described as a standard bean
> as
> well as a "modern" bean. Therefore I have introduced the notion of a
> "model" identified by a URI. I am thinking the URI itself might map to a
> verbal description of the model.
>
> 3. Clazz has a newInstance() method that is responsible for object
> allocation.
>
> 4. You do not get a list of Field objects from a Clazz. Instead, you get
> a
> list of field names and then can acquire a Field object for an individual
> field. The reason is that allocation of Field objects may involve
> multiple
> plugins and therefore be costly. Also, in the case of a Map, we would
> effectively be recreating the map with the Field objects.
>
+1
> 5. Field hides the mechanisms of actual value extraction/manipulation.
> You
> don't get any "readMethods", "writeMethods" etc. You simply delegate the
> value manipulations to the Field object.
>
+1
> 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()?
> 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?
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.)
Victor
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>