Fwd: [TLUG]: ECMAScript ("Javascript") Version 4 - FALSE ALARM

[Dave Herman-2]

> (A fallout of that (my victory or my fault, depending on how you see it)
> is that ES4 does not require things like definite assignment analysis,
> which would have required more elaborate data structures than a compiler
> on an embedded system would be happy with.  Instead we have a syntactic
> workaround (the "settings" section of the constructor) and other rules
> to handle non-nullability.  Kludgy?  Depends on your point of view.

As an aside: in my view this design goal ("no complex static analyses in
the semantics") is not just a win for lightweight devices. It's also a
win for the simplicity of the semantics. A programmer doesn't have to
think about complex analyses to understand the *meaning* of a program;
similarly, when the compiler/interpreter freaks out because an analysis
failed, the programmer doesn't have to understand a complicated error.
Syntactic restrictions like lexical scope, the "settings" section, type
systems, etc. have the benefit of being based on simple syntactic
properties that are easy for the programmer to eyeball by inspection of
the source. The result is a cleaner and clearer language semantics.

Dave
_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Lars Hansen-3]

The intrinsic names are for early binding.  Since the prototypes are mutable nothing is known about their properties.  So code that wishes to early-bind to methods would annotate its variables and open the intrinsic namespace to give preference to intrinsic methods over prototype methods.  The benefits are performance, known semantics, and static type checking (in strict mode).

 

And you are right, they are not interestingly different: they have type annotations.  (Usually, the prototype method calls the intrinsic method after performing type conversions mandated by ES3.  There are a few wrinkles here and there but nothing important.)

 

--lars

---

From: es4-discuss-bounces@... [mailto:es4-discuss-bounces@...] On Behalf Of Maciej Stachowiak
Sent: 31. oktober 2007 12:45
To: Yehuda Katz
Cc: es4-discuss@...
Subject: Re: Language Size (was Re: [TLUG]: ECMAScript ("Javascript") Version4 -FALSE ALARM)

On Oct 31, 2007, at 4:28 AM, Yehuda Katz wrote:

---------- Forwarded message ----------
From: Yehuda Katz <wycats@...>
Date: Oct 31, 2007 3:58 AM
Subject: Re: Language Size (was Re: [TLUG]: ECMAScript ("Javascript") Version 4 -FALSE ALARM)
To: Lars Hansen <lhansen@...>

A massive chunk of these are the duplicate methods in the intrinsic namespace. If you remove those, you actually have very few new classes or methods (see below). Another big chunk is getters and setters that represent old ES3 methods pre-getters and setters.

 

Specifically, removing the duplicate intrinsic methods (but not removing replacing getters/setters, etc.), there are 256 new items on this list, vs. 276 old methods. Hardly "bloated".

That doesn't exactly match my count, but close enough. For ES4 I removed all duplicate intrinsic:: names (not sure what these are for but I'll trust that they are not interestingly different), one of the two String classes, and meta::invoke. For ES3 I did not count [[Call]] internal properties or the like. I get:

ES3: 220

ES4: 437

Seems to be about the same ~2x increase that you report, though we used different methodologies to count. I would not count this as excessive growth, when it comes to the standard library.

Regards,

Maciej

_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Brendan Eich-2]

On Oct 31, 2007, at 5:42 AM, Lars Hansen wrote:

The intrinsic names are for early binding.  Since the prototypes are mutable nothing is known about their properties.  So code that wishes to early-bind to methods would annotate its variables and open the intrinsic namespace to give preference to intrinsic methods over prototype methods.  The benefits are performance, known semantics, and static type checking (in strict mode).

 

And you are right, they are not interestingly different: they have type annotations.  (Usually, the prototype method calls the intrinsic method after performing type conversions mandated by ES3.  There are a few wrinkles here and there but nothing important.)

I changed the subject so it may have been missed, but most of what I wrote at

https://mail.mozilla.org/pipermail/es4-discuss/2007-October/001415.html

which built on Graydon's message at

https://mail.mozilla.org/pipermail/es4-discuss/2007-October/001408.html

was about intrinsic. Hope it helps,

/be

_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Brendan Eich-2]

On Oct 31, 2007, at 4:45 AM, Harri Porten wrote:

> But seriously: from my own work on an ES4 interpreter (based on the
> previous draft back then) I saw the biggest impact on the  
> implementation
> to be in the "compilation phase". This went hand in the hand with the
> *advantages* of the type system, i.e. the possibility to apply
> optimizations before execution.

(Just want to reconfirm that none of these analyses for optimization  
or any other reason are required. Also, FWIW, the more we look at JS  
optimization the more runtime techniques seem to do better; we  
haven't looked at agressive ahead of time compilation techniques of  
course.)

> In my personal book I therefore judge the complexity of a language  
> also
> based on the observation whether runtime implementations typically  
> include
> a compiler, i.e. offer an eval() function or not.

ES4 requires eval, as ES3 did. We're not sure what will become of the  
ES3 compact profile (http://www.ecma-international.org/publications/ 
standards/Ecma-327.htm), but it is a bit of a flop on anything web-
connected. I don't see the need to leave out eval. Flash does  
implement the compact profile, but from the self-hosted ES4 compiler  
that Jeff Dyer has built on top of Tamarin, it looks like Flash will  
have eval too.

/be

_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Brendan Eich-2]

On Oct 30, 2007, at 4:04 PM, Mark Miller wrote:

> AFAIK, the only subset relationships here with unqualified  
> compatibility are JSON < ES3 and JSON < proposed ES4. All the  
> others have hazards that programmers need to understand in order to  
> make use of the subset relationship. In this sense, the situation  
> is analogous to C being approximately a subset of C++: When writing  
> a correct C program, if you know what hazards to avoid, it isn't  
> much harder to write it (without ifdefs) so that it's also a  
> correct C++ program.

Someone just submitted a patch to old C code in Mozilla, to a header  
file. All void f(); prototypes became void f(void); for C++ to be  
happy. This avoided warnings, so it was not strictly required, at  
least not by the compilers we use.

ES4 does not require, or even warn in favor of, any such syntactic  
changes to existing ES3 code.

> Although many may prefer C to C++, no one would propose C as a  
> successor to C++. Nevertheless, it's valuable to both communities  
> to maintain this almost-compatible-subset property between the  
> languages. Likewise, it would make no sense to propose Caja as a  
> successor to ES3.

Sure, but my thought was that a Caja-like language supported by  
browsers might be successful enough that it should be considered for  
standardization. For that to happen (I think), the objections to  
profiled standards would have to be overcome.

> So, depending on what you mean, I might argue with your phrase  
> "incompatible subset". We are seeking to create, as close as we  
> possibly can, a compatible subset. If you see a way in which we  
> could be more compatible while still meeting our other goals,  
> please let us know. Thanks.

I thought I saw something, but I just reread the Caja paper and don't  
see it. Sorry about the false alarm -- it's a proper subset (and well  
done too). Question about it: do you allow the alternative way people  
create prototypes for constructor functions? Instead of

function F(a...){...}
F.prototype.mname = /*method or function*/;
F.prototype.pname = /*expr with no F*/;
...
F.sname = /*function or expr with no F*/;

the following is popular:

function F(a...){...}
F.prototype = {
     mname: function (a,b,c) {...},
     pname: /*expr with no F*/,
     ...
};
F.sname = /*function or expr with no F*/;

> Also, could you explain the phrase "profiled standards"? Thanks.

Standards with a menu of profiles, usually progressively subsetted,  
for implementations to choose from. One example: MPEG-4 has profiles  
(and levels, to support different qualities of encoding that can be  
decoded several ways, IIUC):

http://en.wikipedia.org/wiki/MPEG-4

ECMAScript has a compact profile:

http://www.ecma-international.org/publications/standards/Ecma-327.htm

As the overview for ES4 notes, the Web has not been kind to the  
compact profile. Mobile browser vendors found that, outside of walled-
garden content, they had to implement the full ES3 spec.

It could be that profiles make sense "next time", more than they  
have. It might be a historical accident that ES3 became so  
widespread. Still, people on TG1 who have expressed an opinion about  
profiled standards also worry about the complexity, the size of the  
testing problem in ensuring that the profiles are in a subset  
relation, the specs don't contradict one another, and implementations  
work together. I remember PHIGS and PEX (which makes me think of X  
Windows, and now I'm sad).

>
> Anyway, it's early days for Caja and other such systems. If TG1  
> continues to function, it should definitely harvest good ideas from  
> it, and stand on shoulders, not toes.
>
> Thank you. I will read the ES4 proposal carefully and let you know  
> what shoulder and toe issues I find.

That's great, thanks.

> I would like to hear more about this. A safe eval primitive that  
> provides good isolation could actually be a very powerful lever for  
> expressive security.

A sketch in ES3:

String.prototype.evaluate = function (scope) {
     /* eval this in scope and only scope -- no other scope chain  
contents! */
};

"a + b * c".evaluate({a: 2, b: 5, c: 8}) => 42

For ultimate compatibility and integrity, it might be better to  
provide this only as a fixed static method (can't be replaced or  
overridden due to finality) of string:

string.evaluate(someStringLikeThing, theScoleScopeObject);

/be

_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Brendan Eich-2]

On Oct 31, 2007, at 9:38 AM, Brendan Eich wrote:

> string.evaluate(someStringLikeThing, theScoleScopeObject);

Heh, theSoleScopeObject of course.

/be
_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Kris Zyp-2]

String.prototype.evaluate = function (scope) {
    /* eval this in scope and only scope -- no other scope chain
contents! */
};

 

To me this like an extremely useful feature for security. If future browsers had the combination of some ability to make cross-site requests (JSONRequest or cross site XMLHttpRequest), and this sandboxed eval, with the getters and setters of ES4, developers can create safe sandboxes with host object wrappers with fine grained access control to enable cross site scripts to be loaded and executed with controlled limited ability to interact with environments. I think if we had these capabilities, the most gaping hole in browser security could be effectively dealt with. One thing could make this a little smoother would be a constructor for a global object, with it's own set of global values, Object, Array, etc. for the sandboxed code to mutilate. Nice, but I don't think necessary.

Perhaps, I am missing something, and I don't know for sure how to capitalize the s in security, but this seems a way more valuable asset to security than constraints provided by fixtures and intrinsics.

Kris

_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Brendan Eich-2]

On Oct 31, 2007, at 3:46 AM, Maciej Stachowiak wrote:

I notice some seemingly duplicate features that will perhaps become  

more clear on closer reading of the spec. For instance I see all three  

of namespace, package and unit productions in the grammar. With my  

limited imagination it's hard to think of how those could be three  

interestingly different features.

What's the Sesame Street song? "... one of these things is not like the other, one of these things just doesn't belong."

You are not alone in wondering about these three -- this has come up at past TG1 meetings and we went ahead and implemented to get experience. Michael O'Brien has a small-device implementation that he's posted about here. He may have useful feedback.

This may help separate namespaces and units:

* A namespace is a qualifier on property name (a string in general in ES1-3). It's a prefix to apply to unqualified identifiers used by a block in which a 'use namespace N' pragma occurs at the top. There are sane rules about ordering and ambiguity errors, covered briefly in the overview. As you can see from the RI, namespaces are used heavily. One benefit is to avoid incompatible name pollution of unqualified identifiers in the standard objects and the global object.

* A program unit is an explicit reflection of the Program production's semantics from ES1-3. When you see a program unit body's closing brace, the steps in ES3 Chapter 10.2, plus ES4 steps like those, kick in. You can nest units, and a server framework can expand them server side when they are stated without bodies, but with locators that point to the body in question. This preserves accurate source coordinates for errors coming from nested units, and avoids downloading too many small files. See the proposal for more detail.

These two are genuinely different, orthogonal, and useful things, I think.

* Packages are built on namespaces, and unlike program units they are open-ended. You can keep adding to a package (someone correct me if I'm wrong), by writing

package acme.widgets {

  ...

}

several times in a row. As the overview notes, a package has two namespaces, package-public and package-internal. There's an import directive for pulling some or all of the public names of a package into another scope.

/be

_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Brendan Eich-2]

On Oct 31, 2007, at 9:55 AM, Kris Zyp wrote:

> , and this sandboxed eval, with the getters and setters of ES4,  
> developers can create safe sandboxes with host object wrappers with  
> fine grained access control to enable cross site scripts to be  
> loaded and executed with controlled limited ability to interact  
> with environments. I think if we had these capabilities, the most  
> gaping hole in browser security could be effectively dealt with.

There are lots of exploits. Gaping holes that careful JS coders can  
close, with the right tools, should be closed -- first the right  
tools are needed as you note. But defense in depth plus fallible  
human nature mean that no one is ever careful enough. The crackers  
find really subtle holes. Security is never "done". So while I am in  
favor of something like Doug's proposal, I'm not so confident as you  
are.

> One thing could make this a little smoother would be a constructor  
> for a global object, with it's own set of global values, Object,  
> Array, etc. for the sandboxed code to mutilate. Nice, but I don't  
> think necessary.

This is exactly the path we went down. Obviously my a + b * c == 42  
example is a useless toy. Real uses of eval like this will want to  
evaluate complex object graphs, possibly even containing functions.  
It's a sandbox, right? Should be safe. Not so fast:

* Information can flow out of the sandbox as well as into it from the  
evaluated string. What result types should be allowed? If dynamic  
objects, see below.

* From GreaseMonkey experience, the trusted caller of evaluate often  
wants to add new API functions and objects to the sandbox. This  
cannot be done safely in ES3. Among other problems are the mutable  
prototypes, and Function.prototype.call/.apply which fixtures do  
address.

* This kind of sandbox is a leaky reference monitor in general. There  
is no mandatory access control specified for all control flows.  
Implicit flows[*] are unmonitored. We have experience going back to  
Netscape 4 (and earlier) that such a system is "advisory" -- people  
may use it, or not; they may use it in one place and not in another;  
they may use it but it's easy to leak information across the sandbox  
object reference, and out from the return value.

Some proposals have insisted on primitive types only as the result.  
That's insufficient, and judging from real web apps and add-ons such  
as GM, crippling.

> Perhaps, I am missing something, and I don't know for sure how to  
> capitalize the s in security, but this seems a way more valuable  
> asset to security than constraints provided by fixtures and  
> intrinsics.

Please don't set up a false dilemma.

As noted above, without fixtures and other mutability controls  
missing from ES3, you can't safely inject added APIs into the  
sandbox. You can't even trust the sandbox object after the evaluate,  
in the sense that even getting a property from an object in it might  
trigger a getter, with unexpected results. The trust label for the  
getter's code should be other than the trust label of evaluate's  
caller, of course, and perhaps there is a reference monitor comparing  
those labels somehow.

But now the mission creep has turned into a whole new, extremely  
"researchy", mission, until ES4 specifies mandatory access control  
(MAC) and even non-interference: secure information flow: public and  
secret inputs to a program only mix in secret outputs, never in  
public outputs.

Security is never simple, and from our experience in Mozilla, it  
actually hurts to be simplistic about things like an eval sandbox.

Nevertheless! I'm in favor of something like Doug's proposal, but it  
needs a vigilant detailing and critical thinking about the issues you  
raise, and others. These issues are not peripheral or minor:

* populating the sandbox with standard objects,
* populating it with custom objects,
* explicit result type restrictions,
* sandbox side effect hazards, including code (getters on objects in  
the sandbox, etc.)
* (from the last point) mutation controls in general -- new in ES4,  
not in ES3
* real end-to-end MAC for implicit flows, information security.

/be

[*] http://www.informatik.uni-trier.de/~ley/db/journals/cacm/ 
cacm19.html (ACM members: http://portal.acm.org/citation.cfm?
id=360056 -- anyone know of a free version?)
_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Michael O'Brien-4]

If you come at this (like I first did) thinking of Packages as containers, things can get confusing.

The secret to understanding is to start with namespaces, which are central and critical to ES4 and backwards compatibility. I won't try to describe namespaces here and will leave that to others far more competent than me, but given namespaces, then packages are really just a syntax shortcut for namespaces.

Now you could (as we did), overload the package name as the file name of compiled program elements. However, this has restrictions and complications. It starts burdening package names with meaning you really don't want. Imports directives then become program unit dependencies also.

Unit directives provide an independent naming for how various components of a program will be bundled. Often these do not lie along package or namespace boundaries. Units also provide dependency information.

We use units directives to group program elements and name them as external (pre-compiled) byte code files. In our case, we use the UnitName as  the name of the byte code file. We currently don't use the unit URL. The compiler also has the option to merge all units and dependent units into a single output file. Each unit file can thus have code from one or more packages. Determining the units for an application thus become a loading and network consideration.

So the unit proposal gives flexibility in deciding what program elements should be loaded or transmitted as a unit. This is often independent of and at cross purposes to package or namespace naming.

Michael


Our compiler uses the UnitName of the unit directive to name compiled byte code files.

Brendan Eich wrote:

On Oct 31, 2007, at 3:46 AM, Maciej Stachowiak wrote:

I notice some seemingly duplicate features that will perhaps become  

more clear on closer reading of the spec. For instance I see all three  

of namespace, package and unit productions in the grammar. With my  

limited imagination it's hard to think of how those could be three  

interestingly different features.

What's the Sesame Street song? "... one of these things is not like the other, one of these things just doesn't belong."

You are not alone in wondering about these three -- this has come up at past TG1 meetings and we went ahead and implemented to get experience. Michael O'Brien has a small-device implementation that he's posted about here. He may have useful feedback.

This may help separate namespaces and units:

* A namespace is a qualifier on property name (a string in general in ES1-3). It's a prefix to apply to unqualified identifiers used by a block in which a 'use namespace N' pragma occurs at the top. There are sane rules about ordering and ambiguity errors, covered briefly in the overview. As you can see from the RI, namespaces are used heavily. One benefit is to avoid incompatible name pollution of unqualified identifiers in the standard objects and the global object.

* A program unit is an explicit reflection of the Program production's semantics from ES1-3. When you see a program unit body's closing brace, the steps in ES3 Chapter 10.2, plus ES4 steps like those, kick in. You can nest units, and a server framework can expand them server side when they are stated without bodies, but with locators that point to the body in question. This preserves accurate source coordinates for errors coming from nested units, and avoids downloading too many small files. See the proposal for more detail.

These two are genuinely different, orthogonal, and useful things, I think.

* Packages are built on namespaces, and unlike program units they are open-ended. You can keep adding to a package (someone correct me if I'm wrong), by writing

package acme.widgets {

  ...

}

several times in a row. As the overview notes, a package has two namespaces, package-public and package-internal. There's an import directive for pulling some or all of the public names of a package into another scope.

/be

_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss
  

_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Brendan Eich-2]

Yes, good points:

* Packages de-sugar to namespaces, pragmas, and a missing primitive  
akin to gensym, to make the unforgeable package-public and package-
internal namespaces. They're almost totally syntactic conveniences.

* Along with reflecting the Program production's semantics, program  
units allow programmers to express and check dependencies -- the two  
forms: unit reference, 'use unit [locator]'; and unit provision 'use  
unit [locator] { body }', are the familiar require/provide verbs from  
other languages. This is a critical missing feature from ES1-3.

/be
_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Jeff Dyer]

I made an attempt to size the ES3 and ES4 grammars by assigning an ES
edition number to each production, sorting and counting both concrete and
abstract forms. Below are the numbers I came up with. This are very rough,
but having implemented parsers for ES3, AS3 and ES4, the ~2x increase in
number of productions feels about right.


                 ES3   ES4
                 ---   ---
Concrete         238   490
  Type Exprs            50
  Classes & Interfaces  23
  Patterns              17

Abstract          33    77


Methodology:

1/sort grammar productions and AST constructors by version
2/count concrete productions for each version
3/sort grammar productions by AST constructor
4/eliminate duplicate constructors
5/sort AST constructors by version
6/count AST constructors for each version

The spreadsheet I used is posted in PDF and XLS formats here:

  http://ecmascript.org/es4/spec/grammar.pdf
  http://ecmascript.org/es4/spec/grammar.xls

Jd  

On 10/31/07 3:46 AM, Maciej Stachowiak wrote:

>
> On Oct 30, 2007, at 1:23 PM, Maciej Stachowiak wrote:
>
>> By the way, I think the discussions about language size could benefit
>> from some quantitative data. I think the following comparisons would
>> be interesting:
>>
>> 1) Size of the ES4 grammar relative to the ES3 grammar (say, by count
>> of productions).
>
> Excluding the lexical grammar, the E4X syntax rules (which won't be a
> normative requirement) and regular expression syntax, I count:
>
> ECMA-262 3rd Edition: 74 grammar productions
> ECMAScript 4th edition draft: 197 grammar productions
>
> That's a more than 2x increase in surface syntax (2.66x to be more
> exact). While not completely unreasonable given all the new features,
> it seems a little high. Before embarking on this exercise I thought
> that 2x would be a reasonable level of core syntax increase. Part of
> this may be simply due to better factoring of the grammar, and due to
> capturing features like auto semicolon insertion, how if is
> disambiguated, noin contexts, etc in more detail.
>
> A lot of the genuinely new stuff just seems to be fallout from the
> type system.
>
> I notice some seemingly duplicate features that will perhaps become
> more clear on closer reading of the spec. For instance I see all three
> of namespace, package and unit productions in the grammar. With my
> limited imagination it's hard to think of how those could be three
> interestingly different features.
>
>> 2) Size of the ES4 standard library by count of classes, methods and
>> properties.
>
> I'll try to look at this soon, too. I think 4-5x would be about the
> size that would not raise any red flags for me, given how impoverished
> the ES3 standard library is.
>
> Does anyone else have other ideas for objective metrics of language
> size?
>
> Regards,
> Maciej
>
> _______________________________________________
> Es4-discuss mailing list
> Es4-discuss@...
> https://mail.mozilla.org/listinfo/es4-discuss

_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Jason Orendorff]

On Oct 31, 2007 12:21 PM, Brendan Eich <brendan@...> wrote:
> > One thing could make this a little smoother would be a constructor
> > for a global object, with it's own set of global values, Object,
> > Array, etc. for the sandboxed code to mutilate. Nice, but I don't
> > think necessary.
>
> This is exactly the path we went down. Obviously my a + b * c == 42
> example is a useless toy. Real uses of eval like this will want to
> evaluate complex object graphs, possibly even containing functions.
> It's a sandbox, right? Should be safe. Not so fast:

I just want to underscore that last line.

Python has an eval() function that accepts an optional "globals"
argument.  For years Python had with a restricted-execution module
(rexec) built around this feature.  It was in the Python standard
library.  For years they plugged holes as they were discovered.  At
last they gave up.  rexec was removed from the language.  I know of no
other Python feature of that size and importance that has *ever* been
flat-out removed.  It was simply impossible to maintain.  The feeling
was that there were always more holes remaining to be discovered and
exploited, and that the system was fundamentally too fragile to afford
dependable protection.  Nobody volunteered for the hard and endless
work of maintaining it.  There are Python solutions for sandboxing
today, but this particular approach failed.

I think static analysis is a more promising approach.  I also think
ES4 has important stuff to contribute other than sandboxing.

-j
_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Brendan Eich-2]

On Oct 31, 2007, at 10:21 AM, Brendan Eich wrote:

>> One thing could make this a little smoother would be a constructor
>> for a global object, with it's own set of global values, Object,
>> Array, etc. for the sandboxed code to mutilate. Nice, but I don't
>> think necessary.
>
> This is exactly the path we went down.

See http://wiki.ecmascript.org/doku.php?
id=discussion:resurrected_eval#resolved_issues.

/be

_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Kris Zyp-2]

Great to hear this important issue is being thoroughly discussed and
examined.
Thanks,
Kris
----- Original Message -----
From: "Brendan Eich" <brendan@...>
To: "Kris Zyp" <kriszyp@...>
Cc: <es4-discuss@...>
Sent: Thursday, November 01, 2007 3:37 AM
Subject: Re: [TLUG]: ECMAScript ("Javascript") Version 4 - FALSE ALARM

> On Oct 31, 2007, at 10:21 AM, Brendan Eich wrote:
>
>>> One thing could make this a little smoother would be a constructor
>>> for a global object, with it's own set of global values, Object,
>>> Array, etc. for the sandboxed code to mutilate. Nice, but I don't
>>> think necessary.
>>
>> This is exactly the path we went down.
>
> See http://wiki.ecmascript.org/doku.php?
> id=discussion:resurrected_eval#resolved_issues.
>
> /be
>

_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss