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

Mikeal Rogers mikeal.rogers at gmail.com
Wed Nov 2 13:27:24 PDT 2011


On Nov 2, 2011, at November 2, 201110:57 AM, Brendan Eich wrote:

> 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 don't think I've ever heard an active JavaScript developer, who has been programming in JavaScript longer than 6 months, ask for private class or instance variables. Maybe you have, you talk to more people than I do. I do hear this a lot from people who don't use JavaScript and likely won't even if we add it.

> 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.

I would argue that developers who rely on these kinds of assurances are actually slowing down their own, and others, productivity. Assuming they wrote the perfect method and it should never be changed is a grand claim for anyone who isn't Donald Knuth. Assuming that the consumer of their code is responsible for their own bugs if they introduce them with monkey patching class methods seems fair.

I think this is what Jeremy is getting at, not having these features (or at least obscuring their use to be a different, more explicit pattern, using closures) actually leads to longer term productivity and sustainability in the community and I tend to agree

I may have said this before, but the lack of these features may actually be part of what has allowed JavaScript to thrive and, for lack of a better term, to win. Jeremy brought up some compelling examples.

> 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.)

I was just trying to debunk the claim that these features are necessarily faster and will vary with implementation. Most features can lend themselves to optimizations but, as you pointed out, at what cost.

> 
> /be

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


More information about the es-discuss mailing list