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