Bound functions and other gibberish

[rkaw92]

Apparently, this is considered valid (at least on 2.3.1):

var parseFunction = require('parse-function');

function equals(a, b) {
    return a === b || (isNaN(a) && isNaN(b));
}
var boundEquals = equals.bind(global);

// Prints "true"
console.log(parseFunction(boundEquals).valid);

I'm not quite sure if this is the result everyone expects, given that the returned body is " [native code] ".
Even more mind-boggling is this:

parseFunction('function(a, b) { @(!)$!#$E+F#$+#%)$+#OOo.__ - + = = = + // }').valid

In which parallel universe can V8 execute this? The "valid" flag seems misleading. Might be worth adding some warnings to the README.

In particular, assuming " [native code] " is valid may be risky, since a user might not expect their argument information to go away after a .bind(). It may be better to consider unparseable function bodies as invalid as a whole, or provide a run-time flag to enable such behavior (so that the API remains compatible with whatever weird flavor of JS / JSX the user needs).

[tunnckoCore]

Yea, I also noticed the bound problem somewhere before some time.

In which parallel universe can V8 execute this?

😆 👍 The valid don't have meaning that you may expect. It was added, because to determine if "good" input is passed or not, and because I didn't want to throw errors or return falsey value. Its meaning still is partially valid to me. But yea, I maybe should rethink it, I'll recheck.

It may be better to consider unparseable function bodies as invalid as a whole

Good point.

Thanks for the thoughts and using it (if you using it) :)

[tunnckoCore]

parseFunction('function(a, b) { @(!)$!#$E+F#$+#%)$+#OOo.__ - + = = = + // }').valid

I think the reason for that to be even parsed is using acorn.parse_dammit. And there was reason to using it, I don't remember it now.

[rkaw92]

I think it may be beneficial to provide an option to switch to using the more restrictive parser, though I have not checked what acorn emits from .parse for such function strings.

(As a side note, I'm using parse-function for parsing prototype methods, and soon class methods, for automatic exposure via an API in Java-annotation style.)

[tunnckoCore]

I think it may be beneficial to provide an option to switch to using the more restrictive parser

To be clear, you mean option to use .parse instead the default .parse_dammit, right?

If that's your point, great idea. I'll add it.

[rkaw92]

Dnia 14 kwietnia 2016 01:07:41 CEST, Charlike Mike Reagent notifications@github.com napisał(a):

I think it may be beneficial to provide an option to switch to using
the more restrictive parser

To be clear, you mean option to use .parse instead the default
.parse_dammit, right?

If that's your point, great idea. I'll add it.

---

You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
#14 (comment)

Indeed, that is what I meant.

[tunnckoCore]

@rkaw92 what you thinking about switching to babylon?

[rkaw92]

I honestly don't know much about it yet - let me check. Another possibility is esprima. Before choosing, do you think that a switch from acorn is necessary?

[tunnckoCore]

do you think that a switch from acorn is necessary?

Not sure, too. But I think it will be better, because it has support for everything out of the box, without specifying some options. All of them are the same, the question is which is faster. I will do some benchmarks and if babylon is faster than acorn, i'll switch to it.

Another thing is that we can introduce parser option, noted in #23

[tunnckoCore]

It seems it can parse async/await functions even with ecmaVersion: 2017. With parser behind Babel, will be able to have better support for everything and somehow I believe it can be faster.

[rkaw92]

Supporting two parsers sounds like adding ballast that could backfire in the long term, especially if minor differences in the output leak through the abstraction. How well will you be able to unify the return value?

[jamen]

Aren't they unified through the ESTree spec? Babylon has a few notes on deviations from the spec as well.

I've created a few estree-* modules that do operations over those nodes. I haven't tested much with acorn or babylon to be honest, but I would assume you'd be fine because people from both projects collaborate in that ESTree organization.

[tunnckoCore]

@rkaw92 it won't be a problem

@jamen, exactly, there's no diffs in that nodes that we use here.