`Function.toString.call(class Foo {})` should return `class Foo {}`, not `function Foo() {}`. Function#toString is definitely underspecified in ES6, but the current spec text *allows* for the correct representation, and future spec text will require it. Please fix this ASAP.
When implementing methods in class body, what happens? function A() { } A.prototype.method = function () { }; class B { method() { } } In the above case, A.toString() just returns the function code, but B.toString() returns the class body including the method definition. I don't think there should be difference because class declaration behaves like a syntax sugar. So I think waiting the things specified in the spec.
/So I think waiting the things specified in the spec./So I think waiting the things specified in the spec is better./s
In that example - when the method is dynamically added - the "method" function absolutely wouldn't appear. If you define a function's name later, it doesn't affect its string representation. While it's fine to wait, this means it's *impossible* to detect when a "class" was defined using "class" syntax, and also does not comply with how Chrome or Edge does it (although it does comply with how Firefox does it). Waiting for the spec to define it isn't the worst idea, but Chrome and Edge's behavior will almost certainly become the standard - so it'd be nice if WebKit/Safari followed suit.
(In reply to comment #3) > In that example - when the method is dynamically added - the "method" > function absolutely wouldn't appear. If you define a function's name later, > it doesn't affect its string representation. > > While it's fine to wait, this means it's *impossible* to detect when a > "class" was defined using "class" syntax, and also does not comply with how > Chrome or Edge does it (although it does comply with how Firefox does it). Why would you want to detect this? > Waiting for the spec to define it isn't the worst idea, but Chrome and > Edge's behavior will almost certainly become the standard - so it'd be nice > if WebKit/Safari followed suit.
> Why would you want to detect this? There's any number of reasons. When I give them, the typical response is, "don't do that" - ie, determinine if a function will throw on [[Call]], or to help determine `IsConstructor` in an engine that doesn't support `new.target`. I've also written modules that detect if something's an arrow function, or a generator, etc - it's a use case that exists. Sadly, it's impossible without this fix.
This is working as expected now. I believe this was fixed by: Implement Function.name and Function#toString for ES6 class. https://bugs.webkit.org/show_bug.cgi?id=155336 http://trac.webkit.org/r198042 *** This bug has been marked as a duplicate of bug 155336 ***
This is still not fixed in stable, nor in nightly from 2016-06-06. `Function.toString.call(class Foo {})` returns ` "function () { }"` which is decidedly not correct, especially given the `Function#toString` spec changes that are now stage 3 in ECMAScript.
(In reply to comment #7) > This is still not fixed in stable, nor in nightly from 2016-06-06. > > `Function.toString.call(class Foo {})` returns ` > "function () { > > }"` which is decidedly not correct, especially given the `Function#toString` > spec changes that are now stage 3 in ECMAScript. When I run this I get: js> Function.toString.call(class Foo {}) "class Foo {}" I checked Safari Technology Preview Release 5, WebKit Nightly 6/6 (r201731), and a Trunk Build in `jsc` from around 201700 (give or take 15 commits). Could you clarify in what version of WebKit you are testing this?
ahh oops sorry, I was looking at the wrong bugs site :-p this is broken in firefox but works fine in the latest Safari Tech Preview. Thanks for fixing this!! *** This bug has been marked as a duplicate of bug 155336 ***