Partial application should be bound (like bound functions) #634
Description
Activity
Aye. Those tiny implicit funcs should behave like es6-equal-rockets
=>
Another fix would probably be not using classes andshitthisat all.Alright, I think I agree here.
My initial workaround was this:
walkList: (list) !-> {visitors} = @ list |> filter (.type of visitors) |> each @walk
I ultimately ended up working around it by using inner functions, which helped me refactor it to be more functional rather than CoffeeScript-ish OO.
module.exports = (visitors, ast) !--> walkList = each walk, filter (.type of visitors) # more methods
The semantics seem to be a bug, potentially a design oversight in the language, but the workaround eventually helped surface a bad smell in my code.
I still say partial functions should be lexically bound (like ES6 arrow functions).
Okay. After writing a patch that implements this behavior, I realized that it might not always be what you expect. Consider this:
o = a: 1, f: (@a =)
Here unbound
thisis intended.My feelings:
- A bound
thisfeels "right" and might be more common [citation needed], since these implicit functions are intended for writing quick inline lambdas (where you would assume boundthis), not methods - Syntax to support both bound and unbound might be overkill? Crazy idea: pick another sigil for bound
this
- A bound
- added a commit that references this issue
on Feb 1, 2016
It's really confusing to have code like this constantly throw TypeErrors:
The problem is this partial function:
It looks like it should be bound to the current instance, equivalent to this code:
It's really equivalent to this, which was a rather unexpected gotcha:
This gotcha is a little misleading. It feels like a small fix, but I don't know a lot about the internal compiler structure.