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
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
