On Sat, 5 Nov 2022 11:17:04 GMT, ExE Boss <d...@openjdk.org> wrote:
>> @liach
>>
>>> Is there a particular reason we define poll (null on empty) in SequencedMap
>>> but remove (NSEE on empty) in SequencedCollection?
>>>
>>> I understand that SequencedCollection doesn't want to be null-ambiguous,
>>> and map entries are non-null so poll there is not ambiguous. But I still
>>> think using remove for both look more consistent.
>>
>> Yes, this is definitely an asymmetry. I did it this way to avoid
>> proliferation of new methods, so I just promoted existing ones from
>> NavigableMap into SequencedMap. But I might take another swing at this and
>> see if there's a way to get throwing versions into SequencedMap. The problem
>> is that `firstKey` throws if empty but `firstEntry` returns null if empty.
>> So to make things consistently throwing, we'd need to add
>> `getFirst/LastEntry` and `removeFirst/LastEntry` to SequencedMap (and
>> probably get rid of some of the other methods). This would make SequencedMap
>> and probably LinkedHashMap fairly nice, but it would clutter up NavigableMap.
>
> @stuart-marks
>> The problem is that `firstKey` throws if empty but `firstEntry` returns null
>> if empty.
>
> That’s because there’s no way for `firstKey` to distinguish `null` as meaning
> an `Entry` where `getKey()` returns `null`, and `null` meaning no mapping.
>
> Whereas with `firstEntry`, `null` can only be returned when the map is empty,
> because a `null` key mapped to some value would return `Entry[key=null,
> value=…]`.
>
> --------------------------------------------------------------------------------
>
> Another way to think about it is that the default implementation of
> `firstKey()` does:
>
> default K firstKey() {
> return this.firstEntry().getKey();
> }
@ExE-Boss Yes, I'm aware of the problem if `firstKey` were to return null.
(Didn't prevent `Map::get` from being added though.) The problem I was
referring to was one of consistency. We have an uncomfortable mixture of
throwing things and null-returning things. The challenge is to come up with a
reasonable set of things that makes internal sense and that also fits with
what's there already. This might not be possible. Thus, some tradeoffs are
necessary.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1304678458
