On 4/23/21 8:33 AM, Stuart Marks wrote:
This is what I intended anyway, ie that its OK for "first" to work on
an unordered collection, just that addFirst() has very weak semantics
wrt first-ness.
"Ensures that this collection contains the specified element(optional
operation). This has the same basic behaviour as add(E), but
implementations may choose to add the element in first position if
they have some kind of guarantee of ordering. An exception should not
be thrown unless add(E) would also have thrown the exception."
What seems to be going on here is that people want to add generality
by promoting this set of methods from ReversibleCollection up to
Collection. Unfortunately, the only way to do so is to make the
specification so loose that the semantics are destroyed.
Having these methods on Collection could lead to a situation where
calling addFirst and then getFirst might result in getFirst returning
a different element from what was passed to addFirst. This doesn't
make any sense for methods that have "first" in the name.
When making this proposition, I was only thinking of how to enable new
yet-nonexistent operations on collections that have order / are
reversible and that the code calling these methods would already knows
that it is dealing with ordered / reversible collections. I wasn't
thinking about how to prevent mistakes like passing unordered collection
to code that expects ordered / reversible collection. This can only be
solved in two ways. The way immutability of collections is solved (throw
exception in runtime when requesting operation that makes no sense in
unordered collection) or by introducing new type - ReversibleCollection
that solves this in compile time. So I take back my vote for suggestion
to introduce methods like getFirst(), removeFirst() that would return
arbitrary element. There's still a possibility for those methods to
throw at runtime though. But I don't know whether this would be so
nicely accepted as immutability was. WDYT?
Peter
