proposed relationships of Secure EcmaScript, ES3.1, and ES4.

Mark Miller erights at
Wed Feb 20 22:48:37 PST 2008

Hi Brendan, thanks for the long and thoughtful answer. I think we have
many points of agreement.

I'll be responding to your message point by point soon. Tonight I'll
just mention a few that jumped out at me.

On Wed, Feb 20, 2008 at 7:35 PM, Brendan Eich <brendan at> wrote:
>  Now we could say something about the outer language and the kinds of
>  objects that could be injected. But now the secure dialect in the
>  sandbox is spreading its reference monitor or capability system into
>  the outer language, and that outer language can't be ES3, therefore
>  it can't be ES4-in-full (which is a superset of ES3, modulo de-facto
>  standards fixes).

I do not understand this comment, and it seems crucial that I do. Can
you please expand? Thanks.

>  > 4c) At the EcmaScript meeting, I proposed that a function called by
>  > call, apply, or bind should have "this" bound to the first argument of
>  > that call, bind, or apply -- no matter what value that is. In ES3, if
>  > the first argument of call or apply is null or undefined, the
>  > function's "this" is bound to the global object. (If I recall
>  > correctly, there was general agreement with this proposal by itself.
>  > If I'm remembering this inaccurately, please correct me.)
>  The minutes and trac should tell the truth, but I remember general
>  agreement on the global substitution for null and undefined being
>  considered a design flaw in ES3, which introduced call and apply.

That's great. The current behavior created, for Caja, a terrible
privilege escalation vulnerability that we have figured out how to
plug by unpleasant means we have yet to document or implement.
Repairing this behavior will make a future Caja a more tractable and
safer piece of engineering. Thanks!

>  > 5) I propose the addition of Function.prototype.newInstance
>  > (argList) such that
>  >
>  >     f.newInstance([a,b]) ==== new f(a,b)
>  The proposal I like is ... as a unary prefix "splat" operator that
>  mimics ...'s usage in rest parameters:
>    function f( { return new g(; }

When I first saw splat at
<> I immediately liked
it. I was enthusiastic about using it in exactly the way you suggest.
It's a nice idea -- my compliments. However, it fails the "no new
syntax in ES3.1" rule, which I care about even more. Without splat or
newInstance, ES3.1 is otherwise reflectively complete re invocation.
There's no reason that reflective construction needs new syntax, so it
would be a shame to keep it out of ES3.1 only for that reason.

>  > 5a) I separately propose that new f(a,b) be considered sugar for
>  > f.newInstance([a,b]), so that f can override newInstance to
>  > distinguish being invoked as a constructor from being invoked by other
>  > means.
>  This is a nice idea in the abstract, and any middle-aged language
>  that doesn't already follow the Zen of Python's "There should be
>  one-- and preferably only one --obvious way to do it" line could
>  perhaps afford to be expansive, and support both ... as splat and
>  newInstance.
>  However, desugaring new into a call to a metaprogramming function
>  without further security mechanism scares me. Right now a host-
>  provided function object [...]

Ok, you succeeded in scaring me too. I withdraw the suggestion until I
come up with something better thought out. Thanks for catching this

Text by me above is hereby placed in the public domain


More information about the Es4-discuss mailing list