Hi Andy,
Hi Craig,
It sounds like you are thinking that you would like two different
attributes, one for "element-type" and another for "implementation-
type". Can you explain what the difference is? I only see the need
for one value here: the type that can be stored in the field,
element, key, or value.
Lets take the example of Collection. The element-type will be java.lang.Object
(or the interface type when using interfaces). The element-implementation-type
will be the actual PC types stored there. Notice that I said types (plural). The
user wants to store more than one PC type in the same collection, so they
declare
it with element-type as Object. The point of then defining which PC types are
valid is to allow the JDO impl to manage the persistence of this collection.
I understand your scenario that the user wants to store instances of
different PC types in this collection. This means even with JDK 5 you
need to define the field with Collection<Object> in the Java source. The
JDO metadata can be more specific when specifying the element-type. All
you need is the possibility to specify more than just one element-type.
However, I think this can be done using the existing element-type, so I
do not see the need for another metadata element such as
element-implementation-type.
I think the spec could allow that the element-type value is a list of
type names, but I'm not sure whether we should require that every JDO
implementation needs to support multiple element-types. Maybe this
should be an optional feature. The same holds true for multiple type
names in field-type.
Regards Michael
The same applies to a field of type java.lang.Object (or an interface). The user
wants to store some PC type there. In one object it may be a PC type A. In
another object it may be a PC type B. The implementation-type (or field-type in
your case) will be the possible types that can be stored.
In the case of interfaces, we clearly have the "implements" information to
provide this implementation definition, but the benefit of adding an attribute
to
each field/collection/array etc is that the user can then restrict each field to
a subset of the possible implementations.
The TCK, as you currently have it, only typically has one "implementation type".
The real world has many implementation types and the user needs the flexibility
to select from them.
Now that I've mentioned that I have in mind plurals, maybe it would be better to
use XML properly and add a subelement to store the names of these PC
implementation types. It would work with an attribute, storing a comma-separated
list of names, but then XML allows it to be done better than that.
Hope thats clearer.
--
Andy
--
Michael Bouschen [EMAIL PROTECTED] Engineering GmbH
mailto:[EMAIL PROTECTED] http://www.tech.spree.de/
Tel.:++49/30/235 520-33 Buelowstr. 66
Fax.:++49/30/2175 2012 D-10783 Berlin
