Function representation for built-in functions from symbol-valued properties?

[André Bargull]

print(RegExp.prototype[Symbol.match]);
print(Object.getOwnPropertyDescriptor(RegExp, Symbol.species).get);

prints in most engines some variations of:

function [Symbol.match]() {
    [native code]
}
function get [Symbol.species]() {
    [native code]
}

which doesn't match the current requirement:

If func is a Bound Function exotic object or a built-in Function object, then return an implementation-dependent String source code representation of func. The representation must have the syntax of a NativeFunction.

because "[Symbol.match]" and "get [Symbol.species]" can't be matched as IdentifierName.

[Michael Ficarra]

Is this something we want? If this is not consistent, would implementations be willing to change this?

[André Bargull]

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]

[Michael Ficarra]

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?

[André Bargull]

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

[Michael Ficarra]

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.

[HE Shi-Jun]

If user-land getter will still keep function get NAME() {}, we'd better not drop get for consistency.

[Michael Ficarra]

@hax It won't. It looks like a getter.

[HE Shi-Jun]

@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?

[Michael Ficarra]

Yes, something else.

[HE Shi-Jun]

@michaelficarra

It seems there may be expectation that /function (.*?)\(/.exec(func)[1] always return func.name, so that means

1. we should keep function in the result of func.toString()
2. we need also drop get in func.name if we drop get in func.toString()

Am I right?

[Michael Ficarra]

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

[HE Shi-Jun]

@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

[Michael Ficarra]

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