I think option B (three function types) is best because I believe "things
that are different should look different": it reduces surprises,
particularly for new users or when working on code which is new to you.
The way promises were added to JS requires different implementations for
the callback and promise versions, and those two functions have very
different calling sequences so there's no economy to be had by overloading
the function name.
By way of comparison, promises/futures were in a C compiler I used about 15
years ago but this problem didn't come up because "future" was a type
attribute of the variable being assigned, not part of the function being
called, so any expression could be used as a future and the compiler knew a
reference to the variable implied an await().
Lacking type attributes this isn't possible in JS, and keeping track of
"value or promise" is the programmer's responsibility, so syntax that helps
me keep that straight is helpful.
-J
On Monday, April 14, 2014 9:20:05 PM UTC-7, Andrew de Andrade wrote:
>
> So at work we're working on a bunch of node modules that will eventually
> be published as open-source and I'm in favor of callbacks and two of my
> co-workers are in favor of promises. We've discussed supporting both API
> interfaces and I was curious what the general consensus of the community
> was with respect to supporting both and the best way to name functions and
> methods to support both.
>
> That being said, there are three obvious choices:
>
> (a) two function types: (1) synchronous functions; and (2) async functions
> that return promises but also handle callbacks
>
> var value = myFunctionSync();
> myFunction(callback);
> var promise = myFunction();
>
> this approach has a tiny performance overhead (since you have to check if
> the last argument is a function to determine if you should return a promise
> or execute that function as the callback) and makes all the functions a
> little convoluted (unless you make one higher order function that you apply
> to all your callback functions to support both APIs). Furthermore async,
> higher order, overloaded functions or variable arity functions become
> impossible since you can't necessarily assume that the last argument is
> always the callback.
>
> (b) three function types: (1) synchronous functions; (2) async callback
> functions; and (3) async promise functions
>
> var value = myFunctionSync();
> myFunction(callback);
> var promise = myFunctionDeferred();
>
> this is ugly but explicit in terms of what to expect and permits the most
> flexibility.
>
> (c) two function types: (1) synchronous functions; (2) async callback
> functions;
>
> var value = myFunctionSync();
> myFunction(callback);
>
> and promise support is left up to the user by using a nodeify() method
> from a promise library. This is my preference, but won't make my co-workers
> happy.
>
>
> With all this in mind, what's the general consensus of the NodeJS
> community on this issue? I searched google and the archives and could not
> find any blog posts or discussions that address this particular issue. What
> are the pros and cons of each approach? What if any libraries implement
> options (a) or (b)? etc.
>
>
>
--
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
---
You received this message because you are subscribed to the Google Groups
"nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
