Closed undoZen closed 9 years ago
So I merged it in, and tried to write a test, but the test didn't work. There's another level of indirection that this patch isn't addressing. The actual function passed to the callee isn't generated here, it's generated by make_defer_return
here. It's the ret = (inner_args...) ->
that needs to have the right arity, and because it's in a library, I'm not sure how to do it.
eh... then this will be tricky
Do you think use my small module fn-arity here acceptable. It can only handle arity up to 10 but functions checkout callback arity more than 10 is rarely existed.
I often write code like
superagent.get('...').end arity 2, defer err, r
...
really want to get rid of the arity 2, ...
call here.
Oh man, I would hate to make the core potentially unstable to just work around this library. I've never had this particular issue.
:'(
Can you write a thin wrapper around superagent to solve the issue?
Seems like it's a pretty bad hack to behave differently based on the arity of the function you're passed for exactly this reason.
ok. you can revert it. sorry to disturb you by this.
it's no worries, if there were a clean solution that we're certain won't break other things (and will work in the inline runtime and the iced-runtime), let's do it. i don't want to build in the 10-arg limit though, that will surprise people when they least expect it.
Thanks, I'm going to make a few changes to it to keep the constants in one place.