Question on layer/peeling

[Brian Goetz]

Right, thanks.  For #3, we could easily lift these methods to 
primitives.  Which would freak out some users, to see

   1.hashCode()

(but this isn't all that much freakier than the existing

   "".hashCode()

which also freaks some people out.)

There's a relatively short path to getting this working:
  - Compiler accepts invocations of these methods on any-typed 
expressions, and emits calls to the Object methods;
  - Compiler includes receiver metadata in the bytecode mapping 
attribute (already done)
  - Specializer handles the case where you invoke one of these methods 
on a raw "any T" and rewrites as invocations to (say) Integer.toString().

Probably only a few hours of work.

On 1/5/2015 10:52 PM, Michael Barker wrote:
>     The layer part is indeed not yet implemented.  But even a catalogue
>     of where the code can't be made value-clean would be a useful
>     contribution.  We know that the Collections implementation is full
>     of stuff that will be hard to any-fy without help from layering or
>     other tools, but don't yet have a complete catalog.
>
>
> I think I've managed to hit the wall with the current implementation of
> Valhalla.  I think the "implementation by parts" work or something
> similar needs to make progress before moderately complex collections
> like HashMap can be implemented.  So, sticking points thus far.
>
> 1) Nulls - checking against null inputs.  Ideally no-op and always true
> for values.
> 2) Nulls - nulling out reference array elements.  Need some notion of
> "zero" for value types, so that nested value types containing references
> don't leak memory.
> 3) Methods from Object, e.g. hashCode and equals.  At the moment an <any
> T> doesn't have any methods, there's no obvious way to get the hash code
> of, or equate any-type variables.
>
> #1 & #2 can be worked around by simply not doing them and suffering the
> negative effects (NPEs and memory leaks respectively).  I can't find an
> easy way to work-around #3.  It was mentioned that value types will need
> to define hashCode/equals/toString.  If this is the case, should the
> existing primitives support them too, such all possible types of an
> any-typed variable supports said methods?  Obviously this impacts a
> HashMap implementation heavily as it is all about the hashCode and
> equals, but would probably impact an array ArrayList implementation too
> as it requires equals to support contains.
>
> Mike.
>