sentinels & who owns the value space Re: valhalla-dev Digest, Vol 17, Issue 10

[Rezaei, Mohammad A.]

>
>The definition of a 'good sentinel value', is a value the client doesn't
>use.
>

A properly written data structure (see trove, gs collections and koloboke for examples) does
not preclude the client from using the sentinel values in the collection or for other purposes. null is a sentinel in hashmap, yet null keys are fully supported. A properly written data structure hides the actual sentinel values from the client.

>> Scribbling some random bits over their type seems worse.
>
>Can't work reliably.
>

It provably works in C and can work for pure (no ref field) value types in Java. (I'm not saying it's a great idea; we've explored alternatives in another thread on this list)

>What you're proposing would break information theory; client unaware of any
>restrictions on value space and collection picking random sentinels, is
>essentially hoping that "randomness" will somehow enable you to convey more
>information than a byte can hold.

No information theory is broken, because the client does not need to be aware of the internal sentinels
used in the data structure.

Maybe you're confusing API contracts that use constants (like map.get) with real sentinels. The API level issues 
can always be solved in other ways, e.g. calling map.contains first, or using a different form, like map.getOrElse or returning Optional<V> from map.get.

Thanks
Moh