Add experimental support for ES7 function bind. #1518
Conversation
| stage: 0 | ||
| }; | ||
|
|
||
| var CALL = t.identifier("call"); |
There was a problem hiding this comment.
The AST is currently considered to be highly mutable so this isn't really safe to do. ie. properties could be added to it that would cause race conditions when ran multiple times.
RReverser
changed the title
| @@ -214,7 +214,12 @@ pp.parseExprSubscripts = function(refShorthandDefaultPos) { | |||
| } | |||
|
|
|||
| pp.parseSubscripts = function(base, start, noCalls) { | |||
| if (this.eat(tt.dot)) { | |||
| if (this.eat(tt.doubleColon)) { | |||
There was a problem hiding this comment.
In the following case:
new X::y;We want (new X)::y rather than new (X::y). Agree?
Similarly, for:
x :: y :: z We want (x :: y) :: z rather than x :: (y :: z)
So I think we should only eat :: if noCalls is false.
There was a problem hiding this comment.
Thanks Kevin!
As for the first case - makes sense to me.
As for the second one - I don't see any benefits from such construct at all since second .bind anyway doesn't change context of prebound function, so it's kinda convoluted example IMO.
| (_context = ctx, ns.obj.func).call(_context); | ||
| (_context = ns.obj).func.call(_context); | ||
|
|
||
| (_context = ns.obj2, ns.obj1.func).call(_context); |
There was a problem hiding this comment.
@RReverser You were right, and this looks good to me.
There was a problem hiding this comment.
@zenparsing Thanks for confirmation and review in general!
|
@sebmck Can it be merged now? |
| stage: 0 | ||
| }; | ||
|
|
||
| function getTempId(scope) { |
There was a problem hiding this comment.
I think this UID caching might introduce race conditions with nested binding expressions.
There was a problem hiding this comment.
Can you provide any example?
There was a problem hiding this comment.
(I was also worried about that so specifically added complex tests with nested binding expressions - both transformation and execution seem to be fine)
There was a problem hiding this comment.
Yeah, looks like the scoping stuff covers it as the order of evaluation will always be consistent.
There was a problem hiding this comment.
Yeah - and sequence of operations is always like:
- Store context to
_context. - Get
.bind/.callproperty. - Call it with
_contextas first argument.
So, according to semantics, nothing can happen between storing and using _context.
Add experimental support for ES7 function bind.
|
Awesome, thanks! I've added in handling for "static" contexts in commit 724bf52. The scope API methods will need to be refactored/renamed as they're a bit crap. I'll hopefully push this out later tonight. A short blog post would also be awesome if anyone wants to volunteer. |
|
Awesome work, thanks @RReverser and @sebmck. 😄 |
|
@sebmck Cool, thanks. I could do the blog post - but never did them before here, so need some pointers (or maybe @thejameskyle or @zenparsing want to do it). |
|
@sebmck Also, maybe better to release this before writing in the blog so people could actually play with it? |
|
Released as of 5.4.0 💃 |
lock
bot
added
the
outdated
Please review and let me know about possible issues (syntax is somewhat tricky so I could miss some edge cases). /cc @sebmck @zenparsing
Please note that I implemented it as if tc39/proposal-bind-operator#4 would take place.
Closes #1287.