Loyal Opposition to Const, Private, Freeze, Non-Configurable, Non-Writable...

Brendan Eich brendan at mozilla.com
Wed Nov 2 10:57:54 PDT 2011


On Nov 2, 2011, at 9:51 AM, Mikeal Rogers wrote:

> On Nov 2, 2011, at November 2, 20119:30 AM, Quildreen Motta wrote:
>> 
>>> "freeze" does not add anything new to an object. If you don't want to change the shape of an object ... don't change the shape of the object.
>> Again, immutability isn't just about security, but optimisation as well. You could also look at shared-memory threads, because I think they make a hell of an argument for "frozen" objects or immutability.
> 
> The last time we looked at freezing a few core objects in node.js we found that v8 was actually slower with them frozen and backed them out, which is probably a good thing.
> 
> I'm very skeptical of the "new language feature for optimization" argument ever since the static typing debate in ES4 and the tracer work Mozilla did shortly after.

Type inference is doing well for us now. I agree in general.

However, there's a reason Dart did what it did. With JS, you have to guard, or provide an invalidation protocol, in case someone shadows an inherited property:

var a = [],
    b = {m: function (i) { return i * i; }},
    c = Object.create(b),
    d = Object.create(c);

for (var i = 0; i < BIG; i++) {
  a[i] = d.m(i);
  if (rarely(i)) {
    c.m = function (i) { return 42 * i; };
  }
}

This is a contrived case, but in general, because JS objects are mutable, and when they're used as prototypes they stand in for class vtables, something has to pay a price. Either you worry about checking on every d.m(i) call that the cached target method in b is still the one to call, or you emit code that doesn't check but tear it up and throw it away when c.m is injected and shadows b.m.

This is fine with me and worth the price, but it clearly is not for everyone. I'm not just talking about implementors, either. Some users will want to know d.m isn't going to change. They may not want to know that it's b.m, mind you -- they simply won't want that c.m assignment to be legal, or else if they do support such a thing, they don't want it to affect d's "vtable".

Ok, so such people should use another language than JS. Or, perhaps, they could freeze c and b. Then they'd have parity, once V8 and other engines got around to optimizing accordingly. (It's bogus for you to infer too much from the state of optimization vs. new features.)

/be
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20111102/aa5ae883/attachment-0001.html>


More information about the es-discuss mailing list