Hi Craig,
yes, it works now.
> Using a subclass makes it easier to use the "fast" version (if it is
appropriate),
> without having to change all the calling sequences all at once.
I see what you were saying, but by declaring a parameter TreeMap instead of
SortedMap,
it hinders reusability anyway.
Anyway, only in case you consider useful, I could try to help by writing the
FastTreeMap such that
it uses the "super" embeded object for delegation so it can solve both
problems.
You're right, if you're careful it doesn't matter much unless for "artistic
impression".
Can I contribute with a SortedList interface and a SortedArrayList
implementation ?
Basically I hit the wall with java collections because there's a SortedSet
and a SortedMap notion
but they cannot be addressed by indices, whereas in many practical
implementations you
have to address objects by their index as in List, and you want them sorted,
and calling Collections.sort(...) is such a clumsy solutions.
If you think it can be useful, I could donate these to the jakarta-commons
collections package.
Costin
-----Original Message-----
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
Sent: Sunday, May 20, 2001 2:30 PM
To: '[EMAIL PROTECTED]'
Subject: Re: FastTreeMap.java
Thanks for the patch, Costin. I've applied it to the commons collections
(and to Struts, which still uses its own private copy of these). Could
you try the new ones to make sure that they work for you?
On the general issue of "why extend TreeMap instead of just implement
SortedMap", the reasoning was that some people don't think ahead, and
they've defined their method calling sequences using TreeMap instead of
Map or SortedMap as the parameter type. Using a subclass makes it easier
to use the "fast" version (if it is appropriate), without having to change
all the calling sequences all at once.
Implementing SortedMap instead would still not solve the problem of what
happens if new method signatures are added later (although the compiler
would catch it in this case :-). You still need to update these classes
to stay current with the most recent JDK -- the code is still backwards
compatible to older JDKs as long as the method signature differences are
additions, not removals.
Craig
On Fri, 18 May 2001, Cozianu, Costin wrote:
> Hello all,
>
> I'm not sure if it is important, but my Visual Age for java complains that
> Iterator is not visible in FastTreeMap.java because
> there also exists a private Iterator inner class in the base class
TreeMap,
> so the compiler gets confused.
>
> Yes , you can blame it on the compiler but
> I know there are a lot of people that use VAJava, therefore I think that
> maybe it's
> worth making this little modification so we don't have to make it
> by hand every time we import the jakarta-collections in VAJava.
>
> Speeking of FastTreeMap.java, I am confused why it needs to inherit from
> TreeMap.
> The SortedMap functionality is completely implemented by delegation so
> inheriting
> from TreeMap looks rather unnecessary.
>
> The same situation with FastArrayList, FastHashMap. It's not that big of a
> deal but if tommorrow
> Sun issue a JDK 1.4 and adds something to Map for example, and of course
> implemented in HashMap,
> then FastHashMap will still compile beautifully but will produce incorrect
> results at run-time.
>
> My idea is that maybe it's useful to declare only FastTreeMap implements
> Sortedmap
> and the equivalent for other types.
>
> Costin
>
> cvs diff FastTreeMap.java (in directory
>
C:\costin\open-source\jakarta\jakarta-commons\collections\src\java\org\apach
> e\commons\collections\)
> Index: FastTreeMap.java
> ===================================================================
> RCS file:
>
/home/cvspublic/jakarta-commons/collections/src/java/org/apache/commons/coll
> ections/FastTreeMap.java,v
> retrieving revision 1.3
> diff -r1.3 FastTreeMap.java
> 323c323
> < Iterator i = map.entrySet().iterator();
> ---
> > java.util.Iterator i = map.entrySet().iterator();
> 341c341
> < Iterator i = map.entrySet().iterator();
> ---
> > java.util.Iterator i = map.entrySet().iterator();
> 407c407
> < Iterator i = map.entrySet().iterator();
> ---
> > java.util.Iterator i = map.entrySet().iterator();
> 414c414
> < Iterator i = map.entrySet().iterator();
> ---
> > java.util.Iterator i = map.entrySet().iterator();
>
