Skip to content
This repository has been archived by the owner on Jan 25, 2022. It is now read-only.

implementation-dependent round two #23

Closed
jdalton opened this issue Jan 27, 2017 · 1 comment
Closed

implementation-dependent round two #23

jdalton opened this issue Jan 27, 2017 · 1 comment

Comments

@jdalton
Copy link
Member

jdalton commented Jan 27, 2017

I dig the revisions to this proposal 👍!

If Type(func) is Object and IsCallable(func) is true, then return an implementation-dependent String source code representation of func. The representation must have the syntax of a NativeFunction.
Throw a TypeError exception.

I see that it states implementation-dependent string, but then also specifies

NativeFunction:
function IdentifierNameopt (FormalParameters){ [nativecode] }

Is the wiggle room the whitespace around it? For example Chakra and V8 produce:

"function push() { [native code] }"

Where SpiderMonkey and JSC produce:

"function push() {\n    [native code]\n}"

Have you gotten pushback for say standardizing on:

"function push() { [native code] }"

?

@michaelficarra
Copy link
Member

Yes, the wiggle room is in the whitespace and comments. Standardising the toString output for values which are currently only restricted by the NativeFunction grammar was proposed in #21. Closing as duplicate.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants