You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Dec 7, 2020. It is now read-only.
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:
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?
varsomething=ASQ.wrap(obj.methodName);varsomething2=ASQ.wrap(obj.methodName);something(..);// failssomething.call(obj,..);// workssomething2=something2.bind(obj);something2(..);// worksobj.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:
varsomething=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:
varsomething=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?
The text was updated successfully, but these errors were encountered:
Right now,
wrap(..)
forces thethis
binding of its passedfn
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:If you forget, you lose your
this
binding, and things go bummer. Would it be less of a footgun if we passed through thethis
binding?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:Even something else we could do is make that binding be a "soft binding", where it defaults, but lets you override:
That feels the most flexible and useful. But is it? Thoughts?
The text was updated successfully, but these errors were encountered: