Le 28/05/2012 01:37, John J Barton a écrit :
On Thu, May 24, 2012 at 11:10 AM, Brendan Eich<[email protected]> wrote:
David Bruant wrote:
Once we're at it, for the sake of completeness there is probably no harm
in adding a Reflect.setPrototype at this point, is there?
There is, just as there's a cost to Object.setPrototypeOf (the obvious place
to put it to match Object.getPrototypeOf from ES5). Mark pointed out that
he'd have to delete that static method too, and from every frame that might
run SES code. But when mashing up SES and non-SES code, it would be better
not to break the non-SES code by such deletion.
Having only the SES environment's Object.prototype.__proto__ to delete is
better.
How is this this line of reasoning -- which I read as 'support for
SES-environments and non-SES-environments' -- not violating 1JS?
My answer would be "it is" in the sense that SES is a subset of
JavaScript. Very much like Joe-E for Java (I recommand to read the
related paper [1]). But the subset is something really usable. It's also
more about programmer discipline than a new programming language itself.
David
[1] http://www.cs.berkeley.edu/~daw/papers/joe-e-ndss10.pdf
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
