Now sure how many people are up to date with KEEPs...

# javascript

[Edoardo Luppi]

Now sure how many people are up to date with KEEPs, but just for awareness, as soon as companion blocks land, declaring static properties on classes should translate to better JS code.
I have performance-sensitive code where I'm reluctant to declare a companion object because every operation that reaches into that companion checks for its initialization.

For example, a compiled JS constructor might end up being:

constructor(a, b) {
  Companion_getInstance();
  this.a = a;
  this.b = b;
}

where Companion_getInstance() is:

function Companion_getInstance() {
  if (Companion_instance === VOID)
    // Omitted Instantiation
  return Companion_instance;
}

Now with companion blocks, as far as I understand from §4.2.1, properties declared under companion { ... } will translate to proper statics, and not to another lazily initialized instance attached to the outer declaration.

[CLOVIS]

Does that === VOID really create a measurable performance difference?

[Edoardo Luppi]

I have cases where I'm looping over a stream of bytes for example, and yes, for big arrays accessing companion object properties (that aren't const obviously) does have a performance impact.

[Artem Kobzar]

@Edoardo Luppi, at the first look I also thought like this, however (unfortunately), the properties still need to be initialized lazily (but more like the file-level properties)

[Edoardo Luppi]

@Artem Kobzar it is better if that is made clear in the KEEP at this point.
But just to better understand, why should they be made lazy? Doesn't that imply that instead of having one single lazy-init function for the companion, we end up with a lot of lazy-init functions (one per property)?

[Artem Kobzar]

So, the current idea is following. Just like for the file, there will be a static_init function (per-class) which runs all the static initializers (including companion) and the parent static initializers.
Tbh, I don't like it either from a generated code perspective; however, to keep the same semantics across different backends, we have to do so.
I'm really looking forward to migrating to SWC transpilation as the only option to start using deferred imports for this purpose and eliminate all top-level and static initializers.

[Edoardo Luppi]

Yeah all in all, it makes sense considering how statics work in JS classes.
I never understood why they've decided to evaluate statics at module loading... but that's going to be like that forever at this point.

Regarding defer, I guess it becomes an ESM target only feature tho, as - if I understood correctly what you want to do - that requires per-file.

[Edoardo Luppi]

Regarding eager init, I still have hopes for the undeprecation (and expansion of target sites) of EagerInitialization (or the addition of a new annotation prefixed with Js*).