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 <[EMAIL PROTECTED]> 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(...rest) { return new g(...rest); }
When I first saw splat at
<http://bugs.ecmascript.org/ticket/276#comment:9> 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
issue.
--
Text by me above is hereby placed in the public domain
Cheers,
--MarkM
_______________________________________________
Es4-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es4-discuss
