@@initialize, or describing subclassing with mixins

[Boris Zbarsky]

On 6/30/14, 5:37 AM, Jussi Kalliokoski wrote:
> However, the key thing is that it could be applied to any given object, not just
> instances of the host object.

The problem with this is that it requires either allocating the hidden 
state outside the object itself somewhere or requiring all objects to 
have space for this hidden space or both (e.g. allocating some amount of 
space for hidden state in all objects but spilling out into out-of-line 
slots when you want more hidden state than that).

So this fails one of the primary design criteria for @@create: being 
able to explain the existing builtins (both ES and DOM), which allocate 
hidden state inline for efficiency's sake.

I realize you consider this an irrelevant implementation detail, but it 
_is_ important.

> As an example, here's how you could self-host Map in these terms:
> https://gist.github.com/jussi-kalliokoski/5ef02ef90c6cbb8c1a70 . In the
> example, the uninitialized state is never revealed.

Right, at the cost of requiring the symbol thing, which costs both 
performance and memory.

>              DocumentFragment.prototype.appendChild.call(this, value);

This is an interesting example.  How do you expect the appendChild code 
to perform the check that its this value is a Node (not necessarily 
DocumentFragment, note, appendChild needs to work on any node) in this 
case?  Your time budget for this is 20 machine instructions as an 
absolute limit, 10 preferred and your space budget is "as small as 
possible".

(This is not even worrying about the fact that in practice we want 
different in-memory layouts for different DOM objects, that 
Object.prototype.toString needs to return different values for different 
sorts of DOM objects, or that some DOM objects need different internal 
hooks (akin to proxies) from normal objects.)

-Boris