I see the following approach often when working on certain projects that use Node.js and Bluebird.js:
function someAsyncOp(arg) {
return somethingAsync(arg).then(function (results) {
return somethingElseAsync(results);
});
}
This is, creating a wrapper function/closure around another function that accepts the exact same arguments. It seems this could be written more cleanly as:
function someAsyncOp(arg) {
return somethingAsync(arg).then(somethingElseAsync);
}
When I propose it to others, they usually like it and switch to it.
There is, however, an important caveat: if you're calling something like object.function, and the function relies on this (like console.log does), then this will lose its binding. You have to do object.function.bind(object):
return somethingAsync(arg).then(somethingElseAsync).catch(console.log.bind(console));
This does seem potentially undesirable, and the .bind call feels a little awkward. You can't go wrong with the let's-always-do-the-closure approach.
I can't seem to find any discussion on this on google, there doesn't seem to be anything in ESLint about unnecessary wrapper functions. I'm trying to find out more about it so here I am. I guess it's a case of I don't know what I don't know. Is there a name for this? (Useless use of closures?) Any other thoughts or wisdoms? Thank you.
Edit: someone's going to comment that someAsyncOp is also redundant, yes, it is, let's pretend it does something useful.
The discussion here is pretty straightforward. If your function is OK being called directly by the promise system, with the exact arguments and this value that will be in place when its called directly by the promise system and its return value is exactly what you want in the promise chain, then by all means, just specify the function reference directly as the .then() handler:
somethingAsync(arg).then(somethingElseAsync)
But, if your function isn't set up to be called directly that way, then you need a wrapper function or something like .bind() to fix the mismatch and call your function exactly as you want or set up the proper return value.
There's really nothing more to it than that. It's no different than specifying any callback anywhere in Javascript. If you have a function that already meets the specs of the callback exactly, then you can specify that function name as a direct reference with no wrapper. But, if the function you have doesn't quite work the way the callback is designed to work, then you use a wrapper function to smooth over the mismatch.
All callback functions have the same issue with passing obj.method as the callback. If your .method expects the this value to be obj, then you will probably have to do something to make sure that the this value is set accordingly before your function executes. The callbacks in .then() handlers are no different than callbacks for any other Javascript/node.js function such as setTimeout() or fs.readFile() or another other function that takes a callback as an argument. So, neither of the issues you mention is unique to promises at all. It just so happens that promises live by callbacks so if you're trying to make method calls via a callback, you will run into the issue with the object value getting passed appropriately to the method.
FYI, it is possible to code methods so that they are permanently bound to their own object and can be passed as obj.method, but that can only be used in your method implementation and has some other tradeoffs. In general, experienced Javascript developers are perfectly fine using obj.method.bind(obj) as the reference to pass. Seeing the .bind() in the code also indicates that you're aware that you need the proper obj value inside the method and that you have made a provision for that.
As for some of your bolded questions or comments:
Is there a name for this?
Not that I'm aware of. Technically it's "passing a named reference to a previously defined function as a callback", but I doubt that's something you can search for and find useful discussion of.
Any other thoughts or wisdoms?
For reasons, I'm not entirely sure of (though has been a topic of discussion elsewhere), Javascript programming style conventions seem to encourage the use of anonymous inline callbacks rather than defining a method or function elsewhere and then passing that named reference (like you would be more likely to do in many other languages). Obviously, if you put the actual code to process the callback in an inline anonymous function, then neither of the issues you mention comes up. Using arrow functions in ES6 now even allows you to preserve the current value of this in the inline callback. I'm not saying that this is an answer to your question just an observation about common Javascript coding conventions.
You can't go wrong with the let's-always-do-the-closure approach.
As you seem to already know, it's a waste to wrap something if it doesn't need wrapping. I would vote for wrapping only when there's a mismatch between the specification for the callback and the already existing named function and there's a reason not to just fix the named function to match the specification of the callback.
Related
I have an async fn that returns a type, and want to implement Drop on that type that calls another async function. It's not clear how to do this, and I can't find anything in the docs. The most illuminating article I found is Asynchronous Destructors by withoutboats, but I don't really understand the reasoning, or where this feature is at.
It's not clear how to do this, and I can't find anything in the docs
That's because it's not possible; there is no "async Drop". Drop must be synchronous.
See also:
How do I synchronously return a value calculated in an asynchronous Future in stable Rust?
I am looking for the name and info on a pattern (?) that I'm contemplating. As I don't know the name, it's difficult to search for it.
Here's what I'm trying to do, with a totally hypothetical example...
find-flight ( trip-details, 'cheapest') :: flight
I have this public function, find-flight(...), that accepts 2 parameters, trip-details and some instruction to apply. It returns a single flight, not a list of them.
When I call it with 'cheapest', the function will wait for all available flight results to come in from expedia, travelocity, hotwire, etc, to assure the cheapest flight is found.
When I call it with 'shortest-flight', the function would do the same kind of underlying work as 'cheapest' but would return the shortest flight. I'm sure you can come up with other instructions to apply.
BUT! I'm specifically interested in a variant of this: the instruction (implied or not) would be 'I-am-filthy-rich-and-I-want-to-buy-a-ticket-now'. In other words, the function would call all the sources such as expedia, orbitz, etc, but would return the very first internally received result, at any price point.
I'm asking because I want my public function to be as quick as possible. I can think of a number of strategies that would make it respond fast, but I'm not sure that I know which approach would be best considering that the parameter is unknown until called, right?
So I'm thinking about writing various versions of this function that would all be called by the public version. It'd return the first result. Then, the other strategies could optionally be aborted. If I did that, I could get some metrics on the function and further optimize.
If I were to write this in Java, I'd have a bunch of future objects that the function would loop through to see which one is done first. I'd return that one.
What's that called?
It's been proposed that the pattern is called Promise Race
Let foo be sub or method. I have programmed a blocking and an async variant, so looking from the outside the essential difference is in the return value. I first thought of specifying it in the signature, but the dispatcher unfortunately only looks at the incoming end instead of both:
> multi sub foo (--> Promise) {}; multi sub foo (--> Cool) {};
> my Promise $p = foo
Ambiguous call to 'foo(...)'; these signatures all match:
:( --> Promise)
:( --> Cool)
in block <unit> at <unknown file> line 1
Should I add a Bool :$async to the signature? Should I add a name suffix (i.e. foo and foo-async) like in JS? Both don't feel much perlish to me. What are the solutions currently in use for this problem?
Multiple dispatch on return type cannot work, since the return value itself could be used as the argument to a multiple dispatch call (and since nearly every operator in Perl 6 is a multiple dispatch call, this would be a very common occurrence).
As to the question at hand: considering code in core, modules, and a bunch of my own code, it seems that a given class or module will typically offer a synchronous interface or an asynchronous interface, whichever feels most natural for the problem at hand. In cases where both make sense, they are often differentiated at type or module level. For example:
Core: there are both Proc and Proc::Async, and IO::Socket::INET and IO::Socket::Async. While it's sometimes the case that a reasonable asynchronous API can be obtained by providing Promise-returning alternatives for each synchronous routine, in other cases the overall workflow will be a bit different. For example, for a synchronous socket API it's quite reasonable to sit in a loop asking for data, whereas the asynchronous API is much more naturally expressed in Perl 6 by providing a Supply of the packets arriving over the network.
Libraries: Cro::HTTP::Client offers a consistently asynchronous interface to doing HTTP requests. There is no synchronous API.
Applications: considering a lot of my application code, things seem to be either consistently synchronous or consistently asynchronous in terms of their API. The only exceptions I'm finding are classes that are almost entirely synchronous, except they have a few Supply-returning methods in order to provide notifications of events. This isn't really the case being asked about, however, since notifications are naturally asynchronous.
It's interesting that we've ended up here, in contrast to in various other languages where providing async variants through a naming convention is common. I think much of the reason is that one can use await anywhere in Perl 6. This is not the case in languages that have an async/await pair, where in order to use await one must first refactor the calling routine to be async, and then refactor its callers to be async, etc.
So if we are writing a completely synchronous bit of code and want to use something from a module that returns a Promise, our entire cost is "just write await". That's it. Writing in a call to await is the same length as a -sync or -async suffix, or a :sync or :async named argument.
On the other hand, one might choose to provide a synchronous API to something, even if on the inside it is doing an await, because the feeling is most consumers will just want to use it synchronously. Should someone wish to call it asynchronously, there's another 5-letter word, start, that will trigger it on the threadpool, and any await that is performed inside of the code will not (assuming Perl 6.d) block up a real thread, but instead just schedule it to continue when the awaited work is done. That's, again, the same length - or shorter - than writing an async suffix, named argument, etc.
Which means the pattern we seem to be ending up with (given the usual caveats about young languages, and conventions taking time to evolve) is:
For the simple case: pick the most common use case and provide that, letting the caller adapt it with start (sync -> async) or await/react (async -> sync) if they want the other thing
For more complex cases where the sync and async workflows for using the functionality might look quite different, and are both valuable: provide them separately. Granted, one may be a facade of the other (for example, Proc in core is actually just a synchronous adaptation layer over Proc::Async).
A final observation I'd make is that individual consumers of a module will almost certainly be using it synchronously or asynchronously, not a mixture of the two. If wishing to provide both, then I'd probably instead look to using export tags, so I can do:
use Some::Thing :async;
say await something();
Or:
use Some::Thing :sync;
say something();
And not have to declare which I want upon each call.
The situation is this: I want to use a single duktape/C function for all functions I define on my objects + prototypes. For that I have a function map which takes a function name and a callback (a std::function actually) and can so easily do some common processing and have simpler callbacks (can even use in-place lambdas for that).
That already works nicely, with one problem: same named functions on different objects. In order to disambiguate I now use the heap pointer of an object (or a prototype, which is also an object) as further qualifier. Hence when my central duktape/C function is called I first look if the function is global (i.e. is a defined on the global object). If that fails I get the this binding and do a lookup with its heap pointer. If that also fails I walk the prototype chain and see if I can find the function on one of the prototypes.
This works well to 99%, except in cases where I don't have a this binding (or a wrong one, like for Function.prototype.apply()).
My question is therefor: how can I get the original prototype for a function in my central duktape/C callback?
The answer is simpler than I first thought. For that central function map you need to have the function name. That has to be set as property on the function object you create when you define a new function on an object or prototype.
The same approach can be used for the original object/prototype. Simply add a back reference to that to your function object as another property (say "ptr"). With that you can easily get not only the function's name but also the context for it's execution. And no walk of the inheritance chain is necessary since we already have the correct object/prototype.
What's the difference between doThrow() and thenThrow()?
Let's say, we want to mock an authentication service to validate the login credentials of a user. What's the difference between the following two lines if we were to mock an exception?
doThrow(new BadCredentialsException("Wrong username/password!")).when(authenticationService).login("user1", "pass1");
vs
when(authenticationService.login("user1", "pass1")).thenThrow(new BadCredentialsException("Wrong username/password!"));
Almost nothing: in simple cases they behave exactly the same. The when syntax reads more like a grammatical sentence in English.
Why "almost"? Note that the when style actually contains a call to authenticationService.login. That's the first expression evaluated in that line, so whatever behavior you have stubbed will happen during the call to when. Most of the time, there's no problem here: the method call has no stubbed behavior, so Mockito only returns a dummy value and the two calls are exactly equivalent. However, this might not be the case if either of the following are true:
you're overriding behavior you already stubbed, particularly to run an Answer or throw an Exception
you're working with a spy with a non-trivial implementation
In those cases, doThrow will call when(authenticationService) and deactivate all dangerous behavior, whereas when().thenThrow() will invoke the dangerous method and throw off your test.
(Of course, for void methods, you'll also need to use doThrow—the when syntax won't compile without a return value. There's no choice there.)
Thus, doThrow is always a little safer as a rule, but when().thenThrow() is slightly more readable and usually equivalent.