Right now we seem to have two implicit "subclasses" of GetNameInfoReqWrap: one having a .callback property and is used for dns, while the other has .resolve and .reject properties. I would rather make this distinction explicit by having a GetAddrInfoPromiseReqWrap subclass that extends GetAddrInfoReqWrap.

Same for the other wrapper classes.

@TimothyGu I was aiming to avoid a lot of unnecessary duplicate code. The wraps behave exactly the same in the C++ layer.

@cjihrig Yeah I understand. What I'm trying to say is that you can have a JavaScript class that extends GetAddrInfoReqWrap. As long as its constructor calls super() properly it should work just fine. No duplication in C++ needed.

@TimothyGu It still seems a bit complex if we hang all the data (host, port, bindingName, etc.) onto a req wrap with C++ binding even though the C++ binding may not necessarily read those properties from the req wrap. The only property that matters to C++ should be wrap.oncomplete, so it may be cleaner if we create two JS classes, one for the callback and the other one for promises, each with a .handle (or a symbol property) pointing to those req wraps and add the data properties to the JS instances of those classes. Then the main difference between those two classes would just be how we call resolve/reject/callback(null, result)/callback(dnsException(...)) in handle.oncomplete. (That's basically what the two types of wraps do in the fs promises implementation although those are implemented in C++)

(It's a bit unfortunate that the resolves have a ChannelWrap that's not req wrap as _handle though)

On a second thought, it may not be feasible to separate the data properties to an outer object since we have been allowing users to retrieve them via the this bound to the callback...

EDIT: but we do not always bind the callback to the req wrap e.g. dns.lookup('127.0.0.1', function() { console.log(this) } gives you the global.

Should it say something like "the corresponding promises will be rejected with..."?

Good catch. Fixed.

It seems this should be ### level, not ##, to reflect the hierarchy of not-promisified API.

It seems this should be #### level, not ###, to reflect the hierarchy of not-promisified API.

`Promises` -> `Promise`s?

a IPv4 addresses -> IPv4 addresses

a IPv6 addresses -> IPv6 addresses

Missing YAML.

[`dns. -> [`dnsPromises. in all table (with new bottom references)?

This note needs to be promisified)

Can this be renamed to something like CallbackResolver or LegacyResolver to be more clear?

Should this be [`resolver.setServers()`][`dnsPromises.setServers()`]?

In all these hashes, _callback part needs to be deleted.

Maybe show an example with async/await since according to polls that's what most users are doing?

This defacto introduces promise cancellation to Node.js - can we add a note to this that the API for cancellation may change?

Alternatively, we can remove it and revisit.

cancel(), getServers(), and setServers() don't technically use promises (or callbacks for that matter). They are just synchronous methods provided on the Resolver class that are included here too for completeness.

@cjihrig this is a promise cancellation API though since you are rejecting all promises with an error "from a distance".

I'd really prefer it if we took extra caution around it since we'll want one API for cancellation and ideally users can use the same one for say... promisified timers, fs and DNS.

Maybe we can avoid exposing this in the promise API, or rename it to something else?

I'm willing to remove it because it's a simple change. I don't agree with the change though, and I'm very -1 to renaming it.

Removing it until we have a more general strategy about cancellation with async functions SGTM. We can bring this up with TC39 at the next meeting if you'd like.

I would really prefer it if this method dind't do so much explicit construction:

async function createLookupPromise(family, hostname, all, hints, verbatim) {
  if (!hostname) {
    if (all) return [];
   else 
     return { address: null, family: family === 6 ? 6 : 4 };
  }
  const matchedFamily = isIP(hostname);
  if (matchedFamily !== 0) {
    const result = { address: hostname, family: matchedFamily }
    if(all) return [result];
    return result;
  }
  return await new Promise((resolve, reject) => {
    const req = new GetAddrInfoReqWrap();
    // ...
    req.resolve = resolve;
  }
}