Static fields and specialization

[Palo Marton]

One possible solution how to support specialized static fields is to use
same approach as with generic methods. E.g. with this syntax:

private static final <any T> Optional<T> EMPTY = new Optional<T>();

This will compile initializing expression to generic static method:

private static <any T> Optional<T> EMPTY$init() {
   return  new Optional<T>();
}

And all get/set access to EMPTY<T> will use invocedynamic. Bootsrap will
call Optional.<T>EMPTY$init() to get initial value, store it in some holder
object on heap (eg Variable<T>) and returm get/set MethodHandle for that
field.





On Mon, Jan 12, 2015 at 12:44 PM, Palo Marton <palo.marton at gmail.com> wrote:

> Yes, but you can not create specialized implementations for user defined
> value types. So these will be left with much slower implementation.
> Singleton implementation compiles to just 0-1 instructions and
> implementation that allocates new instance will be much slower.
>
> And other problem - such approach is against goals of specialization: You
> will have to write separate code for each primitive type.
>
> Pavol Marton, aSc
> www.asctimetables.com
>
>
>> In the case of Optional.empty() and others like Collections.emptyList()
>> it's a method that you're invoking. There is no need to implement static
>> field specialization. You can just get your specialized implementations to
>> return different singleton instances. Ok - so this means you now have 9
>> empty instances rather than 1 but that's basically nothing in terms of
>> memory consumption. In the case of Optional you already have manual
>> specialisation for 3 primitive cases in the form of Optionalint and friends
>> so its really 9 rather than 4 anyway.
>>
>> regards,
>>
>>   Richard Warburton
>>
>>   http://insightfullogic.com
>>   @RichardWarburto <http://twitter.com/richardwarburto>
>>
>
>