more band aid coming - Object methods on 'any' tvars
MacGregor, Duncan (GE Energy Management)
duncan.macgregor at ge.com
Thu Jan 15 11:09:43 UTC 2015
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.
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.
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.
On 13/01/2015 16:35, "Maurizio Cimadamore"
<maurizio.cimadamore at oracle.com> wrote:
>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:
>The remaining Object methods are unsupported (most of them are related
>to locking ); the only two 'interesting' methods left out are:
>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
>That is: the compared values must have the same static type or the
>compiler will bark.
>I hope you will find this useful.
More information about the valhalla-dev