Discussion Thread: DIP 1042--ProtoObject--Community Review Round 1

[Mike Parker]

 From H. S. Teoh:

On Wed, Jan 12, 2022 at 08:26:17PM +0000, Dom DiSc via 
Digitalmars-d wrote:
[...]
> By far the most classes will contain non-comparable values, 
> because
> there is only a few "completely ordered" things out there, and 
> most of
> them like simple numbers are already implemented.

This makes me question the wisdom of putting opCmp in the common 
base of
all classes.  If only a small subset of classes will be 
comparable with
each other, then .opCmp should be relegated to user class 
hierarchies
where it actually matters. I.e., to classes that implement the
Comparable interface.

The only reason I can think of where one would want to put .opCmp 
in the
common base class of all classes is so that built-in AA's can 
function
with arbitrary classes (i.e., so that the AA implementation is not
constrained to algorithms that don't require orderability of 
class keys
-- e.g., if buckets need to be sorted for efficiency, or the hash 
algo
uses the ordering for some computations). The current AA 
implementation
doesn't need .opCmp, though.  But even if it did, it wouldn't 
actually
matter in practice, because if .opCmp is going to return 
"uncomparable"
for most object pairs, then it's worthless to begin with and 
unsuitable
to build an AA algorithm with.