src: fixup strings, general code cleanup #14937

jasnell · 2017-08-19T05:46:12Z

Some general source cleanups

Reduce duplicate strings
Add AsyncWrap::AddWrapMethods

Checklist

make -j4 test (UNIX), or vcbuild test (Windows) passes
commit message follows commit guidelines

Affected core subsystem(s)

src

Adds `AsyncWrap::AddWrapMethods()` to add common methods to a `Local<FunctionTemplate>`. Follows same pattern as stream base.

addaleax · 2017-08-19T12:34:29Z

src/async-wrap.h

@@ -87,13 +87,22 @@ class AsyncWrap : public BaseObject {
    PROVIDERS_LENGTH,
  };

+  enum Flags {


Since you’re passing it as ints, and since we have C++11 available: How about enum class JSMethodFlags { (which would implicitly have the underlying type int)?

Wrote it this way to be consistent with StreamBase::Flags. Converting these to enum class ... is a bit more involved than I'd like to get here. If we want to convert those, then we can do both AsyncWrap::Flags and StreamBase::Flags at the same time in a separate PR.

refack · 2017-08-19T20:26:51Z

src/async-wrap.cc

@@ -468,6 +468,13 @@ void AsyncWrap::QueueDestroyId(const FunctionCallbackInfo<Value>& args) {
  PushBackDestroyId(Environment::GetCurrent(args), args[0]->NumberValue());
 }

+void AsyncWrap::AddWrapMethods(Environment* env,


Can we bikeshed about the name.
IMHO Add -> Bind and Wrap -> AsyncHooks so BindAsyncHooksMethods

Add -> Bind

Why? I’d disagree.

Wrap -> AsyncHooks

Not the same things.

~~AddAsyncWrapMethods might be more explicit, if you like it.~~ Disregard that, this is static method anyway, so it would always seem redundant.

I felt AddWrapMethods doesn't convey the semantics clearly, so I tried to decostruct, and see what felt wrong.

Add -> Bind

Why? I’d disagree.

Add has (for me) the connotation of creating something new, and since env->SetProtoMethod AFAICT only creates JS binding for an existing native method Bind sounds more appropriate. But we can also extend the existing metaphor and use Set.

Wrap -> AsyncHooks

Not the same things.

Agreed, but AFAIK getAsyncId and asyncReset are new and only used in the context of the hooks so AsyncHooks felt more focused.
Maybe AsyncIDs is even better.

So to sum another option SetAsyncIDsMethods?

On third thought AsyncHooks is not good, although that's the "context", the methods are only used by the hooks, and are not the hooks. so:
+2 for AsyncIDs
+1 for AsyncWrap

I'm -1 on bikeshedding on this actually. Just don't see much point in doing so.

jasnell · 2017-08-20T16:33:14Z

CI: https://ci.nodejs.org/job/node-test-pull-request/9759/

jasnell · 2017-08-21T18:18:59Z

CI is green. One failure there is unrelated.

PR-URL: #14937 Reviewed-By: Anna Henningsen <anna@addaleax.net>

Adds `AsyncWrap::AddWrapMethods()` to add common methods to a `Local<FunctionTemplate>`. Follows same pattern as stream base. PR-URL: #14937 Reviewed-By: Anna Henningsen <anna@addaleax.net>

jasnell · 2017-08-23T17:38:18Z

Landed in 771a03d and 5e7c697

PR-URL: nodejs/node#14937 Reviewed-By: Anna Henningsen <anna@addaleax.net>

Adds `AsyncWrap::AddWrapMethods()` to add common methods to a `Local<FunctionTemplate>`. Follows same pattern as stream base. PR-URL: nodejs/node#14937 Reviewed-By: Anna Henningsen <anna@addaleax.net>