Reference SUB/SEP Value question

[David Chase]

Here’s a first stab at clarifying the problem.
We might need to stab it some more before we are done.

>> 3) I spent some time experimenting with the relationship between a
>> so-called ?Ref? type and a so-called
>> ?Value? type, thought I had some answers, but after whacking on the
> 
> I don't quite understand 3).  Would it help to post some javadoc/test code
> snippets to illustrate?  If you haven't got this handy, we can scrounge
> something out of our prototypes.

I think there are two choices, refSUBvalue and refSEPvalue.

For SUB, you might have a hierarchy that looks like this:

  interface ComplexValue
     class Complex implements ComplexValue
  interface ComplexRef extends ComplexValue, Ref
     class ComplexGeneratedProxy implements ComplexRef

You can do this because a Reference can support all the
methods of Value by fetching the relevant fields etc, plus
it has some more methods for setting those fields.

For SEP, you might have a hierarchy that looks like this:

  interface ComplexValue
     class Complex implements ComplexValue

  interface ComplexRef extends Ref {
     ComplexValue get(); // canonical connection between Ref and Value
  }
     class ComplexGeneratedProxy implements ComplexRef

The main difference is that in the refSUBvalue world, every ref is
implicitly also a value, and that might be convenient, but I think it
has the two problems of tricking people into shooting themselves
in the foot with aliasing, and that ComplexValue is likely to be an
interface with at least two implementations, hence not falling-off-a-log
easy to optimize with ClassHierarchyAnalysis.

In the world where they are separate, the native programmer will
be forced to notice the difference between refs and values, but
ComplexRef (in particular) is very likely to be a single-implementation
interface (the proxy class) and thus will be easy to optimize.
On the other hand, getting your hands on a value will require
a second memory allocation (but perhaps it will be a short-lived
memory allocation amenable to escape analysis).

I think SEP also helps us avoid some overloaded-method-selection
surprises.

TBD are the exact choices for field names in Ref and Value interfaces
when they are separate; I am inclined to give Refs getter methods
that have the same name and signature as those in the Value interface
(hence, an implicit dereference — is this inconsistency okay?)

Did I at least explain what I think the issues are?
I need to test some coding in both models (I’ve tested “sub”)
to see how they compare.

David