[External] : Re: Alternative to IdentityObject & ValueObject interfaces

[Brian Goetz]

My thinking on this topic has evolved a bit.  At first, we thought about 
conditional methods as being completely ad-hoc, such as:

interface List<T> {
     <where T=int>
     long sum();

}

Here, the sum() method exists as an island in various specializations.  
This was practical in the first iteration of the template classfile 
mechanism (the "standing on segments" one), but adds a lot of 
complexity.  Our current thinking is that conditionality comes from 
constraint.  That is, the rules about overloads are performed without 
respect to conditionality, and then the conditionality constraints 
restrict the members of a particular specialization.  So the 
int-sums-to-long example is out, and instead we'd end up with the more 
parametric

     <where T extends Arithmable<T>>
     T sum();

We likely need a better way of describing constraints.  The obvious 
kinds of constraints are `T=int` and `T <: Comparable<T>`, but these 
don't go far enough, nor are they likely to be flexible enough.  The 
general way to describe a predicate on types is type classes.  And "has 
identity" or "has no identity" are easily described by a built-in type 
class, without having to pollute the hierarchy.

The key here for purposes of specialization is that we be able to 
con(dy)jure a constant witness to the type class at the point of 
describing the specialized List, so that witness-provided behavior can 
be folded into the specialized implementation.

> During our various discussions, we've also used `IdentityObject` and
> `ValueObject` as constraints in the t-vars / parametric VM proposal to
> address methods that are only partially applicable.  We've also talked
> about using that as a signal to allow locking and other
> identity-operations to compile inside generic code that we can
> statically know won't have to deal with values.
>
> Does giving up on having VO/IO in the type system change our
> approaches to either the parametric vm future or identity operations
> in generic code?  It sounds like we're willing to give up on the
> second but I don't have a good sense of what this does to the
> parametric VM.
>
> --Dan
>