Will any new features be tied to constructors?

Domenic Denicola d at domenic.me
Wed Jul 1 15:12:32 UTC 2015


From: Allen Wirfs-Brock [mailto:allen at wirfs-brock.com] 

> This is model is, to a first approximation the C++ model and the also the model the ES currently uses for built-ins so I don't expect that UA allocators will have significant difficulties supporting it.

Really?

Right now the UA allocators for all elements contains a single private slot, a pointer to the backing C++ object. Then a whole parallel hierarchy, of the C++ object tree mapping to multiple corresponding JS object trees, follows from this. Private state is, of course, stored in the backing C++ object. Maybe some implementers can correct, but I doubt retrofitting this structure to support additional arbitrary author-defined private slots, introduced at any level in the hierarchy, is at all insignificant.

Similarly, for several V8 built-ins, private state is not done via the allocator at all, but instead via "private symbols" that act quite similar to data properties. They can be added or removed at any time. In short, they're much more part of initialization than of allocation.

I don't think there's anything like the model the ES spec uses in play in implementations. I would anticipate significant difficulties.

> It has lots of very desirable characteristics.  

Forgive me if I am speaking in ignorance. But from what has been presented so far, it seems to have one strongly *un*desirable characteristic, which is that it is no longer possible to decompose a non-custom-allocator constructor into base-class allocator and subclass initialization. That is, previously it was easy to "emulate" the constructor for

```js
class Derived extends Base {
  constructor(...args) {
    super(a, b, c);
    doInitCode(this, ...args);
  }
}
```

via a function

```js
function makeDerived(...args) {
  const o = Reflect.construct(Base, [a, b, c], Derived);
  doInitCode(o, ...args);
  return o;
}
```

This allows you to recover the allocation/initialization split that was lost when moving away from @@create, while still preserving the instantiation reform benefits in the general case.

It sounds like this kind of emulation is not possible with your private state proposal. Whereas, of course, it is possible with weak maps (which exist today) or "private symbols" (what V8 uses today internally).


More information about the es-discuss mailing list