New private names proposal
brendan at mozilla.com
Tue Dec 21 21:38:47 PST 2010
On Dec 21, 2010, at 8:17 PM, Allen Wirfs-Brock wrote:
For safer parallelization: see, e.g., http://www.ics.uci.edu/~franz/Site/pubs-pdf/ICS-TR-07-12.pdf, or its successor: http://www.springerlink.com/content/u16t58805r879263/ (trace-trees of linear SSA, not ASTs, but no matter).
The pattern is pretty common in compilers these days (rustc, the self-hosted Rust compiler, has an immutable AST; McPeak & Wilkerson's Elsa/Oink tools from UCB, which we at Mozilla used at the start for our C++ static analysis work over four years ago, had an immutable AST). It's not AOP.
We're looking into data parallel extensions to JS, not anywhere near ready to propose for standardization, but plausible now given the ability to freeze.
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.
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). 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.
This can of course be done explicitly, but the implicit "private x" or (to a lesser extent) the transposed square-bracket access of implicit soft fields, look strictly easier to use, albeit at the price that dherman pointed out: implicit side table access using property syntax is confusing, it makes for a syntax vs. mental model conflict.
More information about the es-discuss