A DOM use case that can't be emulated with direct proxies
rossberg at google.com
Fri Dec 14 08:36:48 PST 2012
On 14 December 2012 16:54, Mark Miller <erights at gmail.com> wrote:
> Regarding what Andreas said and what Alex +1ed, we already have precedent.
> We already argued through this precedent in committee and agreed. I like
> David's suggestion about how to organize these tests.
Hm, unless you are talking about intl402, I wasn't aware of that.
What's the precedent?
If the non ES tests are separated properly then it's probably less of
an issue, though I still prefer that such tests are under a different
umbrella. Just to make clear that they are not actually testing ES
That is, I'd much rather have a structure like (modulo details of naming):
> On Fri, Dec 14, 2012 at 5:22 AM, Alex Russell <slightlyoff at google.com>
>> +1. What Andreas said.
>> On Friday, December 14, 2012, Andreas Rossberg wrote:
>>> On 13 December 2012 19:21, Mark S. Miller <erights at google.com> wrote:
>>> > On Thu, Dec 13, 2012 at 1:12 AM, David Bruant <bruant.d at gmail.com>
>>> > wrote:
>>> >>> As you say, to remain viable, it
>>> >>> must be done quickly. From previous experience, I suggest that
>>> >>> there's
>>> >>> exactly one way to get quick universal deployment: add a test to
>>> >>> test262 that fails when a browser's WindowProxy object violates this
>>> >>> normative part of the ES5 spec.
>>> >> I feel such a test would rather belong to the HTML DOM. But either
>>> >> way, I
>>> >> agree.
>>> > The spec that it violates is ES5.1. Therefore it will be
>>> > uncontroversial to put such tests into test262.
>>> I have to strongly disagree here. By this argument, we could put in a
>>> test for any JS extension in the world that potentially violates
>>> proper ES semantics. I think test262 should test ECMA-262, nothing
>>> In particular, consider that test262 currently is a headless test,
>>> i.e. no browser needed, a shell like d8 or jsc is enough to run it.
>>> Putting in browser-specific tests would put a _huge_ burden on all
>>> kinds of automated testing environments running this suite.
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>> es-discuss mailing list
>> es-discuss at mozilla.org
> Text by me above is hereby placed in the public domain
More information about the es-discuss