On Nov 2, 2011, at 1:27 PM, Mikeal Rogers wrote: > On Nov 2, 2011, at November 2, 201110:57 AM, Brendan Eich wrote: > >> [vtables vs. prototype properties performance stuff deleted]
>> 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. Why are you talking about private when I was talking about performance issues that might or might not be helped by freeze, seal, and const? > 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. There are lots of people using the closure pattern precisely to have private instance variables. Crock's thin little book recommends 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. Of course I agree, but one size does not fit all in JS. Again, "freedom" includes my ability to fence my yard. If there's an enclosure movement, where the new lords of the land (who stole it fair and square) kick off the tenant farmers and close the commons, then we have a fight and I'm on the same side as you. But that's not what is threatened by providing fencing material and tools. Tools are not moral actors. And really, who is going to enclose the commons and freeze everything? Google? Hah! > 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. I am sure JS has thrived in part because I chose to make it monkey-patchable, but providing integrity features on an opt-in basis does not mean JS won't thrive. It might mean those users who in the future opt into freezing, etc. and make the world too cold find the users have gone to warmer climes on github. That'll be even more convincing proof of your conjecture. >> 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. The VM game continues. My argument in favor of optional integrity features is not about performance, but performance can get better with more lock-down. Again see Dart and the bragging about it compared to JS. Not that this should matter or prevail forever! /be _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
