On Wed, Mar 20, 2013 at 4:47 PM, AJ ONeal <[email protected]> wrote:
> First, I concede to the empirical evidence disproving my assertion that
> the expression was hoisted. I have been shown the light (in a way such that
> it has spoken unto mine own understanding) and I now believe. Thanks
> Geerten.
>
> This is why the paren placement boggles me:
>
> 42.toString() // Errorinated
>
Error, because the "." would otherwise be ambiguous with 42.0 (or something
similar). This ambiguity can also be broken by explicitly including the
decimal point:
42..toString();
"42"
(and no error)
Or by storing the value in a var:
var n = 42;
n.toString();
"42"
(and no error)
> (42).toString() // Successified
>
The grouping operator breaks the parsing ambiguity explained above
> (42.toString()) // BELETED
>
The same parsing ambiguity here, the parens outside have no effect.
>
> I would expect the same behavior here
>
> function () {} ().toString()
>
This is just a syntax error, nothing surprising here. If the function(){}()
was on the right hand side of an unary operator or an assignment, it would
be immediately invoked and since there is no return, the default
|undefined| would be returned—and of course, |undefined| does not have a
"toString()" method, so that would still result in a TypeError
(function () {}).toString()
>
This is legit, the function expression is wrapped in a grouping operation,
so the expression is evaluated and returned—the result of which is a
function object that, of course, has a toString method.
> (function () {}.toString()) // WORKS !?!?!
>
The grouping operation evaluated the function expression and then called
the resulting function object's toString method.
>
> That's why I find it odd that the placement of the parens is unimportant.
>
Who said that? I only said that grouping operation result is the same
outcome in a scenario similar to this:
function foo() {}
foo === (foo)
Because foo just resolves to the foo binding—nothing special.
>
> I don't know what the spec says about it, but the behavior appears
> inconsistent and therefore unintuitive.
>
The spec defines these rules so that parsers can parse source code
unambiguously.
Rick
>
> AJ ONeal
>
>
--
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
---
You received this message because you are subscribed to the Google Groups
"nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
