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