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@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
