Fwd: IdentityObject and InlineObject

[Brian Goetz]

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 <gneppert at web.de>
To: 	valhalla-spec-comments at openjdk.java.net



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!)