Summary
From discussions about the previous weblog entry, I've realized that Collection, Iterator (and Iterable) are all attempts to unify access to containers. Each has strengths and weaknesses, which is probably why we need more than one way to do it.
Advertisement
Iterator/Iterable abstract all containers down to "sequences of something," which is why a Map can be included. And if a method can ignore enough of the details of a container, then it's general-purpose enough to be used with an iterator.
But sometimes you want to write a more specific method, so it needs to know more specific information about the type it's dealing with, so you say Collection, Set, List, Queue or Map.
The fact that Set is an exact image of Collection, while Queue could be effectively disjoint from collection and List and ArrayList are extensions -- well, that still has a design smell about it (I actually don't have a problem with the "optional" method design, although I did at first). And Collection would almost certainly have been better if it had been called "Sequence."
After working with some of the "Abstract" container classes (which make it much simpler to implement your own container), I also wonder if the AbstractCollection didn't come first, and then it just seemed like there needed to be an associated Collection interface.
In any case, I'm now more comfortable with the idea that there isn't necessarily going to be "one form of unification to rule them all." Especially without latent typing; C++ STL algorithms can achieve a lot because C++ templates support latent typing.
Speaking of which, the next weblog entry comes from the last few days of programming around the topic of containers, and it's another example of why latent/duck typing is a very important aspect in a generics implementation.
I wouldn't say that Sequence is a better name than Collection. Sets aren't sequential. Why do you think so? Nonetheless, your comments about the inelegant heirarchy make sense; I don't think any name would really do it. At some point, you can just say it's good enough, even with library design.
It is interesting to observe that apart from Sets and Lists for which the conceptual distinction is quite clear there are "interbred" data structures like Bags that can be seen either as Sets with attached number attributes (iterators work as in Maps) or Lists with "group by" equivalent elements (iterators work as in lists returning elements multiple times). There are IndexedMaps - essentially a product of crossing Maps and Lists. We can also easily imagine SortedLinkedSets where in some cases one would like iterate in the sorting order and to use the order in which the elements were added to the set in the other cases. I think it is quite hard to impose a decent interface implementation sort of unification (Collection, List, Map, Iterable, etc.) on the real variety of container types and still to avoid the explosion of interfaces. The resulting picture would be an extremily unfriendly to a newcomer digraph of container types.
At least at the conceptual high level it might be interesting to look at each container type as an independent box of sorts with several "ports". A port here is defined as a group of methods. Of course different ports may share some of the methods. So when a certain function (sorting, search, etc...) operating on containers were defined it would require a certain type of port (essentially a group of method roles - something like the delegate concept, in which the factual method name is unimportant, and it is only required to have the correct parameters and return type) from a container. Then any container that defines a group of methods matching the "port" contract would qualify.
For instance if one defines a class like:
class SortedLinkedSet {
Iterator sortOrderIterator() {...} Iterator addOrderIterator() {...} int size() {...}
}
and there is a function that would accept a port of type (Iterator itFactoryMethodName(), int sizeMethodName())
both ports (Iterator sortOrderIterator(), int size()) and (Iterator addOrderIterator(), int size()) will be accepted.
Previous Topic
