Fwd: IdentityObject and InlineObject

[Mateusz Romanowski]

Hi Brian,
An aside perhaps, but how would identity-sensitive classes be migrated?

Would all such classes need to use/enhance genetic signature with
IdentityObject to keep binary compatibility with old clients?
Ie.
WeakReference<T extends Object&IdentityObject>

Do you have any thoughts how both forward and backward binary compatibility
could/should be achieved?

Thanks,
Mateusz


On Wednesday, April 15, 2020, Brian Goetz <brian.goetz at oracle.com> wrote:
> 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!)
>
>
>