On 4/27/21 2:25 AM, Peter Levart wrote:
Right, I'm persuaded. Now if only the problems of transition to the usage of new
type that Remi is worried about were mild enough. Source (in)compatibility is not
that important if workarounds exist that are also backwards source compatible so
that the same codebase can be compiled with different JDKs. Binary compatibility is
important. And I guess there is a variant of the proposal that includes
ReversibleCollection and ReversibleSet and is binary compatible.
Yes, the source incompatibilities with the types seem to involve type inference
(e.g., use of var choosing differently based on new types in the library) so it
should be possible to make minor source code changes to adjust or override the type
that's inferred.
On binary compatibility, that comes mostly from the newly introduced methods
(reversed, addFirst etc.) and from adding covariant overrides to LinkedHashSet. I
guess the "variant" you mention is adding new methods with the new return types
(e.g., reversibleEntrySet) instead of covariant overrides. Or was it something else?
Now just some of my thoughts about the proposal:
- SortedSet.addFirst/.addLast - I think an operation that would be used in
situations like: "I know this element should always be greater than any existing
element in the set and I will push it to the end which should also verify my
assumption" is a perfectly valid operation. So those methods throwing
IllegalStateException in case the invariant can't be kept seem perfectly fine to me.
- ReversibleCollection.addFirst/.addLast are specified to have void return type.
This works for List and Deque which always add element and so have no information to
return. OTOH Collection.add is specified to return boolean to indicate whether
collection was modified or not, but Set modifies the specification of that method a
bit to be: return false or true when Set already contained an element equal to the
parameter or not. So ReversibleCollection.addFirst/.addLast could play the same
trick. for List(s) and Deque(s) it would always return true, but for
ReversibleSet(s) it would return true only if the set didn't contain an element
equal to the parameter, so re-positioning of equal element would return false
although the collection was modified as a result.
Anthony Vanelverdinghe replied to both of these points so I'll follow up in a reply
to his message.
- Perhaps unrelated to this proposal, but just for completeness, existing Collection
interface could be extended with methods like: getAny() and removeAny().
Yes, I think there's something going on here, but the issues lead off in a different
direction, which I think would be a distraction from ReversibleCollection. So I'd
like to keep this as a separate topic. (But it's not a prohibition against talking
about them.) Indeed, I see that Henri Tremblay has coincidentally (?) raised a
similar topic, so I'll reply further to his message.
s'marks
