New private names proposal
brendan at mozilla.com
Tue Dec 21 22:14:32 PST 2010
On Dec 21, 2010, at 10:03 PM, Alex Russell wrote:
>> This is not a relevant fear in my view. It's also kind of silly given all the open source JS libraries. If someone did over-freeze, you could stop using their library, or fork and fix it. Libraries that suck tend to die fast.
> That's...an *interesting* reading of recent history.
What recent history? Please cite some specifics.
ES5 isn't even implemented in final versions of shipping browsers, so overuse of its Object.freeze can't be a historical fact yet.
>> Mark did bring up freezing primordials recently, and I know that causes some "Dr. Freeze" fear (even on this list the other year, from Arv, IIRC).
> And from me right this minute.
What are you afraid of?
>> Nevertheless, it's simply not credible that we on TC39 will agree to freeze primordials in any ECMA-262 edition I can foresee.
>> Sometimes fear is an appropriate reaction. The lamb fears the wolf. When some overwhelming force threatens you, be afraid. But there is no Freeze Force both willing and able to take over the JS world.
>> We don't need to be afraid of well-used immutability for safety and parallelization. Such filter-pipeline architectures do need weak maps or better to associate filter-specific fields with shared immutable data.
> So long as the application of freezing is restricted to the uses at hand and doesn't find its way into the drinking water (ice-nine style).
I've used that metaphor, it is apt when transitively freezing a graph, while developing your freeze-based code.
As a runaway that freezes the web, forever? C'mon. It's not even plausible as a worm vector, let alone a standardization mistake that developers reject. I'm not sure what we are talking about at this point (I hope not "Cat's Cradle").
More information about the es-discuss