Le 18/02/2014 16:02, Boris Zbarsky a écrit :
On 2/17/14 4:27 PM, David Bruant wrote:
That said, it'd be excellent if Blink and Moz completed the current test
suite (Promise/A+)
Mozilla did, until we just removed cast(). Or at least we passed the
test suite at http://domenic.me/aplus-tests-against-the-browser/
sure they implement the same thing to the finest detail
That's laughable, I'm sorry. That test suite is not even close to
testing "finest details". See
https://bugzilla.mozilla.org/show_bug.cgi?id=945766#c4 (and comment 6)
and https://bugzilla.mozilla.org/show_bug.cgi?id=939332#c12 (and
comment 15).
I realize that my use of the word "completed" above does not mean what I
intended. What I meant was "it'd be excellent if Blink and Moz made the
test suite more complete" (which in French I'd express as "...que Moz et
Blink complètent la suite de tests"), but after reading up on the word
"complete" in English, it looks like what I wrote didn't convey what I
meant.
Sorry for the miscommunication.
Anyway, I think we agree that the current test suite is lacking details
and mutualizing the effort by adding tests to the current test suite can
only be better for the web.
I guess contributing to the Promise/A+ repo works.
When I'll find the courage and time, I'll document the test262 test
runner (and maybe add support for async tests), because putting test262
on Github [1] is good, but the bar to contribute is still way too high.
(and report spec issues if such a thing arise).
It's hard for me, as an implementor, to tell to what extent
subclassing support here is a bug vs a feature... It forces some
operations to be done generically in ways that are pretty weird. For
example, Promise.all calls C.cast() via Invoke, which means it might
not actually get back the sort of promise "new C" would produce, or in
fact not get back a promise at all. Then it calls nextPromise.then()
via Invoke, which means it can get whatever the heck the callee wants
to do there.
And of course the fact that the spec is still not updated to the
latest decided-on changes makes it pretty hard to tell whether what
we're shipping matches the spec in any way. We basically implemented
based on a promise (pun intended) that the changes are just to rename
"cast" to "resolve" and remove the old "resolve", but we have no idea
whether that's what the spec will actually end up saying.
Yes, exactly this sort of issues :-)
(note: it's been months that I'm completely behind on promises
discussions. Pretty much at the point where the words "auto-unwrapping"
and "monadic" arrived on es-discuss. I really wish I could deeply
understand these two paragraphs and provide a sensitive suggestion)
David
[1] https://github.com/tc39/test262/
For anyone who cares, apparently sth stands for "Simple Test Harness"
https://github.com/tc39/test262/blob/master/test/harness/sth.js
_______________________________________________
dev-tech-js-engine-internals mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
