Static fields and specialization

[Palo Marton]

> That sounds fundamentally okay, but probably also requires a typed static
> initialiser syntax for fields that could throw an exception during
> initialisation.
>

You can wrap such initialization to generic method by yourself:

static final <any T> MethodHandle mh=mh_init();

static <any T> MethodHandle mh_init() {.....throw...}

Supporting "<any T> static {... }" will bring many challenges with order of
execution for such initializes.


>
> Something like
>
> static final <any T> MethodHandle mh;
>
> static <any T> {
>         try {
>                 // Do MethodHandle lookup
>         } (catch e) {
>                 Throw new Error();
>         }
> }
>
> Duncan.
>
> On 12/01/2015 12:51, "Palo Marton" <palo.marton at gmail.com> wrote:
>
> >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>
> >>>
> >>
> >>
>
>