Closed anba closed 6 years ago
Is this something we want? If this is not consistent, would implementations be willing to change this?
To be a bit more specific than "prints in most engines some variations [...]".
JSC and SpiderMonkey both print:
function [Symbol.match]() {
[native code]
}
function get [Symbol.species]() {
[native code]
}
V8 prints:
function [Symbol.match]() { [native code] }
function get [Symbol.species]() { [native code] }
Chakra prints:
function [Symbol.match]() { [native code] }
get [Symbol.species]
Again, is that something we find useful? Do users of the language actually want to see
function get [Symbol.species]() { [native code] }
or is that just confusing them?
If it is confusing, can we find a better representation? For example if we end up with using function () { [native code] }
for all built-in functions which are accessors or are stored in symbol-valued properties, it may give a worse debugging experience for users.
(I guess what I really want to say is, that function get [Symbol.species]() { [native code] }
may not be the best representation, but at least it gives some kind of hint which function we're working with, whereas function () { [native code] }
gives no info at all.)
If we're okay with dropping get
, we can expand NativeFunction
to use PropertyName
instead of IdentifierName
. I think that would be a good compromise.
If user-land getter will still keep function get NAME() {}
, we'd better not drop get
for consistency.
@hax It won't. It looks like a getter.
@michaelficarra
It won't.
So you mean this proposal will make
Object.getOwnPropertyDescriptor({ get f() {} }, 'f').get.toString()
not return function get f() {}
anymore,
but return function f() {}
or something else?
Yes, something else.
@michaelficarra
It seems there may be expectation that /function (.*?)\(/.exec(func)[1]
always return func.name
, so that means
function
in the result of func.toString()
get
in func.name
if we drop get
in func.toString()
Am I right?
@hax See #17. Also, it seems you haven't read this proposal. Only function declarations and function expressions will produce something that looks like that. Web compatibility has essentially been confirmed by Firefox shipping this for 8 months now.
@michaelficarra
I ensure you I already read the proposal and most issues in this repo, but sorry I have no idea it will cause change Object.getOwnPropertyDescriptor({ get f() {} }, 'f').get.toString()
from function get f() {}
to something without function
or get
.
I hope such change would be more explicit in somewhere.
And I don't think #17 answered my question, it didn't mention getter/setter at all.
Web compatibility has essentially been confirmed by Firefox shipping this for 8 months now.
Sorry, I didn't know it. And it seems not complete shipped in FF because
Object.getOwnPropertyDescriptor(document.__proto__, 'head').get.toString()
still returns
"function get head() { [native code] }"
And even now, I am still confused, while FF already drop function
for user-land getter/setter, but you said:
If we're okay with dropping
get
@hax
I hope such change would be more explicit in somewhere.
The proposal states in the introduction as one of its goals,
for functions defined using ECMAScript code, toString must return source text slice from beginning of first token to end of last token matched by the appropriate grammar production
Additionally, nearly the entire spec text deals with saving the source text slice. I don't know how one could read the proposal and not get this.
And it seems not complete shipped in FF because ...
Yes that is exactly what this open issue is about: built-in getters. My response to you was referring to getters defined in your program because you said "user-land getter".
And even now, I am still confused ...
In my quote, I was talking to @anba about built-in getters, which again is what this currently open issue is all about.
prints in most engines some variations of:
which doesn't match the current requirement:
because
"[Symbol.match]"
and"get [Symbol.species]"
can't be matched asIdentifierName
.