Function.prototype.qcall

[kriskowal]

Function.prototype.qcall

[domenic]

In my experience, the majority of Node functions end up needing the this parameter, so this wouldn't work too well. You'd end up having to say

dynodeClient.putItem.bind(dynodeClient).qcall(...)

which is hardly a win :-/

[rauschma]

I’m arguing for two variants: qcall with thisand qfcall without this. But having just a single variant (with this) is fine, too – the extra null is not a deal-breaker and people are already used to Function.prototype.call.

Do you agree that it would be nice to add such a method to Function.prototype?

[domenic]

Right, sorry, my mistake. Hmm. I'd say it would be nice indeed. It would need an opt-in line, e.g.

Q.extendFunctionPrototype();

which increases friction a bit. But still, could be useful.

[rauschma]

+1

[domenic]

@kriskowal thoughts?

[kriskowal]

I like the idea. I would call it install.

I am reticent to monkey-patch though. Part of the purpose of the library is to encourage patterns that will continue to function in one of MarkM’s VATs. This might be worth batting around on the q-continuum mailing list to see if we hear objections from our mentors in the security business.

On one hand, I like the idea of encouraging standards-track patterns through monkey-patching. I am on the other hand not sure whether this would qualify.

[kriskowal]

A Q.fcall however might be in order, to avoid the thisp.

[rauschma]

Yes, I understand why you hesitate. More options:

1. Use Q itself for calling:

   Q(func, arg1, arg2, ...)
   Q(obj, obj.method, arg1, arg2, ...)  // optional thisp as the *first* argument (obj vs. function)
   

   The idea is to make things look as much like function calls and method calls as possible.

2. Use Q to wrap a value, jQuery-style:

   Q(func).ncall(arg1, arg2)
   Q(obj.method).ncall(obj, arg1, arg2)
   Q(obj, obj.method).ncall(arg1, arg2)  // not sure if this is a good idea
   

[domenic]

Q itself can't be a function call, because that conflicts with Q.call and Q.apply.

Also, option #1 is very "nodeback"-centric; remember most users of Q will not be using it in conjunction with nodebacks, except at certain, hopefully very hidden, seams.

[rauschma]

Right. I still like the idea of putting thisp first, but it might confuse some people.

Q.nfcall(func, arg1, arg2, ...)
Q.nfcall(obj, obj.method, arg1, arg2, ...)  // thisp as optional first arg (obj vs. function)

[domenic]

Yeah, I don't think that makes much sense, compared to Q.call.

[kriskowal]

I have decided not to modify the function prototype in this library. I would however be willing to entertain this more ambitious mission in my long-neglected QQ project. I would also be willing to entertain giving anyone interested in the library ownership of the project.

I think object-first variants of Q.call, Q.apply, and Q.bind would be confusing in the presence of the existing function prototype methods of the same name. I do agree that they make more sense visually, but there’s always Q.invoke and Q.post for method calls. Q.invoke(object, "name", …args) and Q.post(object, name, [args]).

I will entertain here a pull request for Q.fcall and Q.fbind for no-thisp variants of Q.call and Q.bind. Naturally, the same methods would be reflected on promises as promise.fcall and promise.fbind. Let’s track the discussion of those features on the pull request. I am closing this issue as won’t fix.