ES6,ES7,ES8 and beyond. A Proposed Roadmap.
Mark S. Miller
erights at google.com
Sun Apr 21 18:29:18 PDT 2013
Agreed that Object.freeze does not give you what you need.
RiverTrail already needs a kind of collection that is transitively
immutable by construction. They need this for safe data parallelism. But
the reason they are safe for parallel access within a vat/worker is the
same reason they would be safe to pass-by-sharing between vats/workers that
share an address space. And between address spaces, including between
machines, they would be passed by copy, but without any observable
difference beyond performance. We should keep this in mind as we proceed on
the RiverTrail work.
On Sun, Apr 21, 2013 at 3:49 PM, Sam Tobin-Hochstadt <samth at ccs.neu.edu>wrote:
> Then consider `Object.freeze(console)`.
> Fundamentally, frozen objects are not appropriate for prohibiting shared
> On Sun, Apr 21, 2013 at 6:44 PM, Kevin Gadd <kevin.gadd at gmail.com> wrote:
> > isn't typeof (console.log) "function" and not "object"? by object I
> meant an
> > Object object, not 'any arbitrary JS value'. I suppose the distinction is
> > really blurry, and you would still have to deal with problems like the
> > object's prototype chain containing callables...
> > On Sun, Apr 21, 2013 at 3:42 PM, Sam Tobin-Hochstadt <samth at ccs.neu.edu>
> > wrote:
> >> On Sun, Apr 21, 2013 at 6:33 PM, Kevin Gadd <kevin.gadd at gmail.com>
> >> > if I called Object.freeze or Object.seal on a JS object would it
> >> > actually be
> >> > safe to pass it to another thread and let both threads use it without
> >> > any
> >> > locking or guards?
> >> No, it's not safe. Consider Object.freeze(console.log).
> >> Sam
> > --
> > -kg
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss