[concurrency-interest] need to use collection.sort w. CopyOnWriteArrayList
Osvaldo Pinali Doederlein
Wed, 02 Jun 2004 14:25:02 -0300
Joshua Bloch wrote:
>> I suppose we could have methods like sort() added to the List interface.
> It violates compatibility to add a method to a widely implemented
> interface such as List, so this is not a possiblity.
Yes, at this time this would be a major problem(*). I was thinking in
new interfaces, like Sortable, that could be implemented by concrete
classes like ArrayList but not extended by the interfaces. This would
avoid (most) compatibility issues, even though not a perfect design
either; people would need casts like ((Sortable)myList).sort() to not
hardwire code to the concrete classes...
(*) Except that, if everybody who implements (say) List do it indirectly
by subclassing an abstract class, like AbstractList, that takes care of
all generic methods (sort() would certainly fit here), then there's no
problem even in modifying the interface. But I realize that Java's
concern for backwards compatibility doesn't allow statements like
"properly written code won't have problems" in critical cases like this.
>> I never understood
>> why the Collections framework choose this anti-OO design of having most
>> algorithms as statics of utility classes like Arrays and Collections.
> To keep the core interfaces small, general, and learnable. For the most
> part, we are very happy with the design.
I see (oops!). I think I'm more biased by the design of Smalltalk --
collections packed with utility methods -- but of course, in ST, adding
methods is not a burden to existing code. Anyway, when it comes to API
complexity I don't see the advantage of making the collection interfaces
simpler if you need large utility classes like Collections and Arrays
with lots of methods that the programmer quickly needs to learn anyway.
And in this form, these methods are a more complex API because they
don't benefit from inheritance and polymorphism, so we have a larger
number of signatures and even methods names (i.e., unmodifiableList(),
unmodifiableMap(), etc.). But it's just IMHO here.
Now that I think about other languages, it seems that Tiger is instead
moving towards the model of C++ here. In the STL, the decoupling of
containers from algorithms works well, but only because all algorithms
are global functions, so it's not a problem that they're not members of
containers. Now, Tiger allows to static-import classes like Collections
and use a style similar to C++: "sort(myList)". This is convenient, but
it doesn't solve Guy's problem. (C++ solves it with massive overloading
and template specialization, but in Java this would break encapsulation
as we'd need to stuff methods optimized for concrete collections in the
Collections class.) If you replicate the sort method as a static of the
concrete class, and the programmer static-imports these too, and their
more specific signature guarantees precedence, then "sort(myList)" would
invoke CopyOnWriteArrayList.sort(CopyOnWriteArrayList). But it's a huge
hack, horrible design, and abuse of static imports :-(
Osvaldo Pinali Doederlein Visionnaire Informática S/A
Arquiteto de Tecnologia +55 (41) 373-7400 #228