Question on layer/peeling

[Vitaly Davidovich]

Nothing freaky about this :) in fact, had value types been there since day
1, I'm sure the primitives would've been defined as value types and thus
have those methods.  To mimic that in today's world via specializer,
allowing a call to a method defined on Object against "any T" seems legit.
Some people will complain that you can't do the same to a naked primitive
(I.e. 1.hashCode) outside the specialization context, though, I suspect ...

Sent from my phone
On Jan 5, 2015 11:37 PM, "Brian Goetz" <brian.goetz at oracle.com> wrote:

> 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.
>>
>>