Le 11/12/2012 21:46, Brandon Benvie a écrit :
http://github.com/benvie/continuum - project
http://benvie.github.com/continuum - debugger
npm module 'continuum'
Continuum is a virtual machine for executing ES6 code (the spec is
rapidly iterating so many things need updating). It's written in ES3
and targets a baseline of IE8 (debugger included). With a small amount
of additional work it could run reliably in engines as old as IE6, but
this hasn't been a priority.
Almost all ES6 features are supported to some degree: modules,
Proxy/Reflect, Map/Set/WeakMap, generators,
destructuring/spread/rest/default params, __proto__, classes, Symbols,
Typed Arrays/DataView (all features work in any host engine that can
run Continuum).
Awesome :-)
The only remaining features which are unimplemented are tail call
optimization (incomplete and disabled pending some changes), array
comprehensions, generator expressions, and new parts of the binary
data API (structs, etc.). Some features are incomplete and potentially
buggy, especially ones which are completely new and have a lot of
surface area not covered by test262 (proxies
I've started a test suite at https://github.com/DavidBruant/ProxyTests
It was just for me at first, so I started with QUnit (I'll probably
change that eventually). My end goal is to write test for the internals
of built-in algorithms; proxies exposes them, I'd like to be sure that
there is some minimum test suite that shows spec deviations for these
(and why not see if proxies make engines crash when applying built-in
algorithms)
There is only one branch and I'm in the middle of a refactoring :-s
I think you can start with this commit
https://github.com/DavidBruant/ProxyTests/commit/ea53adb659230219a29435a06254dcda2228d80f
until I'm done with the refactoring (then, I'll use different branches
and be more clean in my commits and history)
Tests are aligned with the current direct proxies strawman. (not sure
I'm 100% up-to-date when it comes to the enumerate trap signature, I'll
have to check)
generators especially). I intend to start creating test cases for
these features as soon as I finish fixing out the remaining test262
tests that Continuum fails.
I'd like to point out that I've sent feedback [1][2][3] after my work on
the test suite. I'm more and more convinced that writing test suites is
an excellent opportunity to see corners that weren't seen before. I'd
say that this exercise is complementary to the spec editing work based
on which Allen and wiki.ecmascript editors regularly sends feedback to
the list too.
I've posted (and Andreas before me) about built-in algorithms being
frozen as soon as proxies are released. I take writing tests for that as
an opportunity to carefully review these algorithms and maybe suggest
changes if applicable. I don't think anyone really want to spend time
reading algorithms and imagining how proxies would interact with them.
Writing tests is a good excuse to do this exercise.
And... there will be a test suite as outcome, but the way I see it, the
process of writing the test suite is actually more important than the
outcome itself.
So, yes, if you do want to write tests for any feature, I strongly
encourage you to do so. I strongly encourage anyone reading this message
to do so.
David
[1] https://mail.mozilla.org/pipermail/es-discuss/2012-September/024808.html
[2] https://mail.mozilla.org/pipermail/es-discuss/2012-October/025555.html
[3] https://mail.mozilla.org/pipermail/es-discuss/2012-September/025032.html
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
