Hello, Tom.
Thanks for the pointers and suggestions. I have to claim responsibility
for adding Generics to our Iterators. As you might have seen, the code
has a number of "archaeological" artifacts revealing my slowly emerging
[and incomplete] understanding of Generics. At this point, some of the
Iterators take wildcards with bounds, while others don't. Some of those
are intentional, some of those are just the result of not going back
and revisiting every Iterator's implementation with each bit of
understanding. :) Generics, for the most part, make our lives easier
when using them, but definitely complicate our lives when
trying to implement them. :) I'll see what I can do.
Thanks.
Brian
Tom Mutdosch wrote:
Hi Karen,
Okay, I see the reasoning behind the decision now. Seems like Generics
sometimes complicate scenarios rather than make life easier :)
In looking at the code, it seems that one possible solution might be to
instead make the CloneIterator utilize the wildcard, rather than the
IPersistentType interface. So the CloneIterator constructor would look
like:
public CloneIterator(Collection<? extends E> c) {
this(c, Mutator.ReadOnly.<E>instance());
}
This then allows you to do the behavior you need of using a
CloneIterator on subclassed types:
Collection<JavaPersistentAttribute> atts = new ArrayList
<JavaPersistentAttribute>();
CloneIterator<IPersistentAttribute> ci = new CloneIterator
<IPersistentAttribute>(atts);
So the attributes() method specified by the interface could still be
left pure:
public Iterator<IPersistentAttribute> attributes() {
return new
CloneIterator<IPersistentAttribute>(getAttributes());
}
And you could have another non-interface method on
JavaPersistentType/XmlPersistentType for the internal classes accessing
it directly (versus via the IPersistentType interface) that returns an
Iterator of type-specific attributes:
public Iterator<JavaPersistentAttribute> javaAttributes() {
return new
CloneIterator<JavaPersistentAttribute>(getAttributes());
}
Then clients could use the clean API, and your internal Java-specific
classes could use the specific javaAttributes().
I'm not a Generics expert either, so keep that in mind :) This was
just one idea that seemed like it could work.
Thanks
Tom
Karen Moore wrote:
Hi Tom,
Funny you should ask, I just struggled with this very recently. In our
model JavaPersistentType and XmlPersistentType both implement
IPersistentType. They each have collections of more specific
attributes JavaPersistentAttribute and XmlPersistentAttribute. The
reason I changed the interface to have a wildcard-parameterized type
was so that I could use a CloneIterator (our own utility class) in
JavaPersistentType.attributes() to prevent concurrent modification
problems we were having. I did not change allAttributes() because
those iterators could contain xml and java PersistentAttributes due to
inheritance hierarchies that could possibly span both java and
orm.xml. I don't know that it is possible to use the
wildcard-parameterized type in those situations.
I agree this solution is not the best, we have compiler warnings in
JavaPersistentType that we haven't yet fixed. Given that background and
the fact that I am fairly new to generics, do you have any suggestions?
The method you are writing looks very similar to some of our interface
methods. You might want to take a look at
IEntity.primaryKeyColumnName() and IEntity.primaryKeyAttributeName().
thanks,
Karen
_______________________________________________
dali-dev mailing list
dali-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dali-dev
|
