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

H. S. Teoh hsteoh at quickfur.ath.cx
Thu Jan 13 00:21:08 UTC 2022


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.


T

-- 
Life begins when you can spend your spare time programming instead of watching television. -- Cal Keegan


More information about the Digitalmars-d mailing list