Skip to content
This repository has been archived by the owner on Dec 7, 2020. It is now read-only.

should contrib's wrap(..) pass-thru this binding? #48

Closed
getify opened this issue Jul 10, 2014 · 0 comments
Closed

should contrib's wrap(..) pass-thru this binding? #48

getify opened this issue Jul 10, 2014 · 0 comments
Assignees

Comments

@getify
Copy link
Owner

getify commented Jul 10, 2014

Right now, wrap(..) forces the this binding of its passed fn function to be ø (an empty DMZ object). So, if you need to wrap a this-aware function (aka "method"), you have to call .bind(..) yourself at time of wrapping:

var something = ASQ.wrap( obj.methodName.bind(obj) );

something(..);

If you forget, you lose your this binding, and things go bummer. Would it be less of a footgun if we passed through the this binding?

var something = ASQ.wrap( obj.methodName );
var something2 = ASQ.wrap( obj.methodName );

something(..); // fails
something.call(obj, ..); // works

something2 = something2.bind(obj);
something2(..); // works

obj.something = something;
obj.something(..); // works

Not sure if this feels better or more footgun'ish. It does preserve the flexibility to have an asynquence-wrapped function that can still be bound to another this later if needed.


I don't really want to complicate the API with another utility that handles this binding, but we could do this I guess:

var something = ASQ.wrap( obj.something, { this: obj } );

something(..); // works

Even something else we could do is make that binding be a "soft binding", where it defaults, but lets you override:

var something = ASQ.wrap( obj.something, { this: obj } );

something(..); // works against `obj`
something.call( obj2, .. ); // also works, but against `obj2`

That feels the most flexible and useful. But is it? Thoughts?

@getify getify self-assigned this Jul 10, 2014
@getify getify closed this as completed in 03c83cd Jul 11, 2014
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant