more band aid coming - Object methods on 'any' tvars

[Maurizio Cimadamore]

On 15/01/15 11:09, MacGregor, Duncan (GE Energy Management) wrote:
> Okay, I¹ve used this to write a little toy hash table. These methods do
> not work if the type is concrete at compile time, which feels weird. I can
> call toString() on an int provided the compiler doesn¹t know it¹s an int.
Right - I should have included that in the 'limitations' section - i.e.

1.toString() won't work.

>
> Part of implementing my collection involved making a suitable Optional<any
> T> style type, and this turns out to be slightly more fiddly than I might
> have hoped as there is no way to specify a default value for any val.
There might be some updates soon in that department :-)
> Java.util.Optional<T> defines EMPTY as an optional with its final field
> set to null, but I can¹t do that across any T. I¹ve worked round the
> problem by using two subclasses, Empty<T> (which doesn¹t have a value
> field), and Present<T> (which does and always initialises it), but this
> only works because my Optional is a reference type, and I don¹t think we
> really want Optional type things to be ref types in the long run.
I think some of the proposals I've seen on the table were about using an 
extra boolean in order to capture the 'is present' info.

Maurizio
>
> Duncan.
>
> On 13/01/2015 16:35, "Maurizio Cimadamore"
> <maurizio.cimadamore at oracle.com> wrote:
>
>> Hi,
>> in order to further facilitate experiments with the current prototype,
>> I've put together a compiler/specializer patch that adds some restricted
>> support for calling 'harmless' Object methods on 'any' type-variables.
>> Methods currently supported are:
>>
>> * toString
>> * hashCode
>> * equals
>>
>> The remaining Object methods are unsupported (most of them are related
>> to locking ); the only two 'interesting' methods left out are:
>>
>> * clone
>> * getClass
>>
>> While it wouldn't be impossible to support them in the future, they are
>> not as straightforward to get to (esp. getClass) - and we decided to
>> leave them out for now.
>>
>> One caveat about using Object methods on 'any' type-variables is that
>> the signature of 'equals' is stricter; that is, you can imagine that an
>> 'any' type-variable T defines a method
>>
>> equals(T)
>>
>> and not
>>
>> equals(Object)
>>
>> That is: the compared values must have the same static type or the
>> compiler will bark.
>>
>> I hope you will find this useful.
>>
>> Happy hacking!
>>
>> Maurizio
>>