Object.prototype.* writable?

Mark S. Miller erights at google.com
Sat May 7 20:21:31 PDT 2011

On Sat, May 7, 2011 at 8:04 PM, Kyle Simpson <getify at gmail.com> wrote:

> Good, we're making progress. Previously I was not responding to your
>> original request, I was responding to your response to Crock's message.
>> Hence our confusion about premises. Thanks for making your's clearer. As for
>> your original request, now that I better understand what you're looking for,
>> I think SES is again a good answer. Should SES become a directly supported
>> standard, there would be some opt-in as you suggest. For now, for SES as
>> implemented on ES5 <http://codereview.appspot.com/4249052/>, the interim
>> opt-in is to run initSES.js first in the JavaScript context in question. In
>> the case of a browser frame, the interim opt-in is to place
>> <script src="initSES.js></script>
> Unfortunately, we're back to the chicken-and-the-egg... if I could
> guarantee that my code was the first to ever run on any page, almost none of
> the problems I'm complaining about would be an issue, because I could just
> make sandboxed copies of what I needed, and store them privately inside a
> closure. Being able to "run-first" is the key component that isn't true, and
> if it were true (which is required of "initSES.js"), then I wouldn't need
> "initSES.js".
> So, while I agree that the direction of SES seems to be along the lines I
> am asking for, the interim story doesn't really hold much water. The good
> news is that some movement is happening toward it. I hope that continues.
> Is the thought that you would have a similar opt-in to "SES" as you do
> "strict mode", eventually? Or something else?

Similar. But it does need to be different because strict mode is per script
within a context, whereas SES needs to be per context. That's why, within a
page, the opt-in needs to be page-wide, and the opt-in needs to be noticed
by the browser before it starts executing scripts on that page.

At <http://wiki.ecmascript.org/doku.php?id=harmony:module_loaders>,
the Loader.createBase() and Loader.create(base, resolver) APIs enable the
creation of a new context and a new module loader which will load modules
into that context, respectively. This allows opt-in to SES post frame
creation, by creating a new context and loading the SES code into that

What I here call "context" that strawman calls "base library", and
corresponds to the unique set of primordial non-host objects currently
created by creating a new browser frame.

> --Kyle
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110507/34afcb49/attachment.html>

More information about the es-discuss mailing list