Agree with all you said. And practically speaking, if I intend to support these things in a piece of software I've written then somewhere, somehow, there needs to be a way to tell that they work. Right now there's a lot of things that ostensibly are supported by Continuum but for which the way to see if it works is to attempt to run code that uses the feature and see if it breaks or not.<div class="gmail_extra">
<br><br><div class="gmail_quote">On Tue, Dec 11, 2012 at 4:31 PM, David Bruant <span dir="ltr"><<a href="mailto:bruant.d@gmail.com" target="_blank">bruant.d@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Le 11/12/2012 21:46, Brandon Benvie a √©crit :<div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<a href="http://github.com/benvie/continuum" target="_blank">http://github.com/benvie/<u></u>continuum</a> - project<br>
<a href="http://benvie.github.com/continuum" target="_blank">http://benvie.github.com/<u></u>continuum</a> - debugger<br>
npm module 'continuum'<br>
<br>
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.<br>

<br>
Almost all ES6 features are supported to some degree: modules, Proxy/Reflect, Map/Set/WeakMap, generators, destructuring/spread/rest/<u></u>default params, __proto__, classes, Symbols, Typed Arrays/DataView (all features work in any host engine that can run Continuum).<br>

</blockquote></div>
Awesome :-)<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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<br>

</blockquote></div>
I've started a test suite at <a href="https://github.com/DavidBruant/ProxyTests" target="_blank">https://github.com/<u></u>DavidBruant/ProxyTests</a><br>
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)<br>

There is only one branch and I'm in the middle of a refactoring :-s<br>
I think you can start with this commit <a href="https://github.com/DavidBruant/ProxyTests/commit/ea53adb659230219a29435a06254dcda2228d80f" target="_blank">https://github.com/<u></u>DavidBruant/ProxyTests/commit/<u></u>ea53adb659230219a29435a06254dc<u></u>da2228d80f</a> until I'm done with the refactoring (then, I'll use different branches and be more clean in my commits and history)<br>

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)<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
</blockquote></div>
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.<br>

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.<br>

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.<br>
<br>
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.<br>
<br>
David<br>
<br>
[1] <a href="https://mail.mozilla.org/pipermail/es-discuss/2012-September/024808.html" target="_blank">https://mail.mozilla.org/<u></u>pipermail/es-discuss/2012-<u></u>September/024808.html</a><br>
[2] <a href="https://mail.mozilla.org/pipermail/es-discuss/2012-October/025555.html" target="_blank">https://mail.mozilla.org/<u></u>pipermail/es-discuss/2012-<u></u>October/025555.html</a><br>
[3] <a href="https://mail.mozilla.org/pipermail/es-discuss/2012-September/025032.html" target="_blank">https://mail.mozilla.org/<u></u>pipermail/es-discuss/2012-<u></u>September/025032.html</a><br>
</blockquote></div><br></div>