java.util.java.util
regarding sets, collections, lists and maps, but with more
analysis.java.util and UK.ac.lancs.sets.These classes are intended to address a couple of problems with the
standard package java.util.
The first problem is the under-analysis of lists and collections, etc.
One is forced to implement the entire interface of, say, java.util.Map just to have some simple static, immutable mapping.
Much of the work on these classes is about analysing the original
interfaces to give different levels of detail. For example, at the
simplest level, a map simply converts an input value to an output
value, so our basic interface PureFunction has only the
get(Object) method. The next step up is the
Function, which inherits from PureFunction
and has extra methods to determine whether a given input value
(i.e. key) is in its domain. It doesn't know what values are in its
range, and its domain may not be finite, so you can't iterator over
it.
After that comes the FiniteFunction, whose domain you can
iterate over, but still doesn't know its range set. The
ReadableMap is next, and does know its range, which can
be iterated over. Finally, we reach
uk.ac.lancs.sets.Map, which has all the methods of
java.util.Map, plus a few extra because of similar
analysis applied to sets.
(This plan could back-fire! The analysis of lists and iterators requires multiple inheritance (so there is no choice but to use interfaces), but the classes that implement these are going to be more restricted.)
The second problem is the existence of java.util.Set —
it's virtually pointless! It is derived from java.util.Collection, overrides all the existing methods, then fails
to add any more. So, in terms of compilation, it is identical to its
base class, and doesn't actually impose any further requirement on its
implementation than Collection does. The excuse appears
to be that alternative documentation can be added to explain that a
Set should have set semantics (i.e. no duplicate
entries), while a Collection doesn't have to, and method
signatures can express whether they want a supplied collection to have
set semantics or not. However, since Set imposes no
further requirements on its implementation than does
Collection, it's perfectly legitimate to have a
Set implementation without set semantics, or a
non-Set Collection with set
semantics. I also don't find the documentation benefits compelling.
For these reasons, java.util.Set does not have any
analogue in this distribution.