ReversibleCollection proposal

Peter Levart peter.levart at
Sun Apr 25 18:09:04 UTC 2021

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?


More information about the core-libs-dev mailing list