Received on the -comments list.
It is tempting to reach for an "implementation by parts" approach like
this, but unless we go the extra mile and teach the compiler to "stitch
together" these two partial methods into a total method, it doesn't work
so well. Instead, we can lean on an existing overloading:
Heap<T> heapify(Object... args) { ... }
Heap<T> heapify(IdentityObject... args) { ... }
where the former is essentially the inline version, since the existing
most-specific-overload rules will select the latter when the arguments
are known to be IdentityObject. So we don't give up much here.
Moreover, this overload points to the real distinction we want -- has
identity vs not. Inline-ness here is just the absence of identity, so
(at least for this purpose) doesn't need its own interface. (There may
be other reasons we'll discover later, though.)
-------- Forwarded Message --------
Subject: IdentityObject and InlineObject
Date: Tue, 14 Apr 2020 11:02:02 +0200
From: Gernot Neppert <[email protected]>
To: [email protected]
After reading through Brian Goetz's arguments in favour of abandoning
'InlineObject', I was wondering:
Couldn't it be useful to be able to overload a function based on the two
disjunct type-families?
For example, it may turn out to be more efficient to use two different
algorithms for inline- vs. non-inline types. So I might want to write this:
<T extends InlineObject> Heap<T> heapify(T...args) {
}
<T extends IdentifyObject> Heap<T> heapify(T...args) {
}
(If we had only 'IdentifyObject', the overload-set would contain
functions with non-disjunct argument-types, which is generally discouraged!)
