On Nov 2, 2011, at 1:27 PM, Mikeal Rogers <[email protected]> wrote:
>
> 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.
>
The module pattern, arguably one of the most common JS patterns out there is
predicated on making internal variables 'private' via a closure, and only
returning a 'public' API. For any class/type defined, there are vars that are
likely to be only used within the implementation or they are vital to the
class/type contract. Both are compelling reasons to have private.
>> 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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
