Skip to content

Commit e3187cc

Browse files
committed
doc: copyedit addons doc
PR-URL: #4185 Reviewed-By: Roman Reiss <[email protected]> Reviewed-By: Michaël Zasso <[email protected]>
1 parent 213ede6 commit e3187cc

File tree

1 file changed

+29
-27
lines changed

1 file changed

+29
-27
lines changed

doc/api/addons.markdown

+29-27
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
# Addons
22

3-
Addons are dynamically linked shared objects. They can provide glue to C and
3+
Addons are dynamically-linked shared objects. They can provide glue to C and
44
C++ libraries. The API (at the moment) is rather complex, involving
55
knowledge of several libraries:
66

@@ -11,11 +11,11 @@ knowledge of several libraries:
1111

1212
- [libuv][], C event loop library. Anytime one needs to wait for a file
1313
descriptor to become readable, wait for a timer, or wait for a signal
14-
to be received one will need to interface with libuv. That is, if you
14+
to be received, one will need to interface with libuv. That is, if you
1515
perform any I/O, libuv will need to be used.
1616

17-
- Internal Node.js libraries. Most importantly is the `node::ObjectWrap`
18-
class which you will likely want to derive from.
17+
- Internal Node.js libraries. The most important class is `node::ObjectWrap`
18+
which you will likely want to derive from.
1919

2020
- Others. Look in `deps/` for what else is available.
2121

@@ -28,7 +28,7 @@ be used as a starting-point for your own Addon.
2828

2929
## Hello world
3030

31-
To get started let's make a small Addon which is the C++ equivalent of
31+
To get started, let's make a small Addon which is the C++ equivalent of
3232
the following JavaScript code:
3333

3434
module.exports.hello = function() { return 'world'; };
@@ -68,11 +68,11 @@ Note that all Node.js addons must export an initialization function:
6868
There is no semi-colon after `NODE_MODULE` as it's not a function (see
6969
`node.h`).
7070

71-
The `module_name` needs to match the filename of the final binary (minus the
72-
.node suffix).
71+
The `module_name` needs to match the filename of the final binary (excluding
72+
the .node suffix).
7373

7474
The source code needs to be built into `addon.node`, the binary Addon. To
75-
do this we create a file called `binding.gyp` which describes the configuration
75+
do this, we create a file called `binding.gyp` which describes the configuration
7676
to build your module in a JSON-like format. This file gets compiled by
7777
[node-gyp][].
7878

@@ -89,13 +89,13 @@ The next step is to generate the appropriate project build files for the
8989
current platform. Use `node-gyp configure` for that.
9090

9191
Now you will have either a `Makefile` (on Unix platforms) or a `vcxproj` file
92-
(on Windows) in the `build/` directory. Next invoke the `node-gyp build`
92+
(on Windows) in the `build/` directory. Next, invoke the `node-gyp build`
9393
command.
9494

9595
Now you have your compiled `.node` bindings file! The compiled bindings end up
9696
in `build/Release/`.
9797

98-
You can now use the binary addon in an Node.js project `hello.js` by pointing
98+
You can now use the binary addon in a Node.js project `hello.js` by pointing
9999
`require` to the recently built `hello.node` module:
100100

101101
// hello.js
@@ -114,7 +114,7 @@ Below are some addon patterns to help you get started. Consult the online
114114
[Embedder's Guide][] for an explanation of several concepts used such as
115115
handles, scopes, function templates, etc.
116116

117-
In order to use these examples you need to compile them using `node-gyp`.
117+
In order to use these examples, you need to compile them using `node-gyp`.
118118
Create the following `binding.gyp` file:
119119

120120
{
@@ -127,7 +127,7 @@ Create the following `binding.gyp` file:
127127
}
128128

129129
In cases where there is more than one `.cc` file, simply add the file name to
130-
the `sources` array, e.g.:
130+
the `sources` array. For example:
131131

132132
"sources": ["addon.cc", "myexample.cc"]
133133

@@ -234,7 +234,7 @@ the full `module` object as the second argument. This allows the addon
234234
to completely overwrite `exports` with a single function instead of
235235
adding the function as a property of `exports`.
236236

237-
To test it run the following JavaScript snippet:
237+
To test it, run the following JavaScript snippet:
238238

239239
// test.js
240240
var addon = require('./build/Release/addon');
@@ -344,8 +344,8 @@ To test:
344344

345345
### Wrapping C++ objects
346346

347-
Here we will create a wrapper for a C++ object/class `MyObject` that can be
348-
instantiated in JavaScript through the `new` operator. First prepare the main
347+
Here, we will create a wrapper for a C++ object/class `MyObject` that can be
348+
instantiated in JavaScript through the `new` operator. First, prepare the main
349349
module `addon.cc`:
350350

351351
// addon.cc
@@ -365,7 +365,7 @@ module `addon.cc`:
365365

366366
} // namespace demo
367367

368-
Then in `myobject.h` make your wrapper inherit from `node::ObjectWrap`:
368+
Then, in `myobject.h`, make your wrapper inherit from `node::ObjectWrap`:
369369

370370
// myobject.h
371371
#ifndef MYOBJECT_H
@@ -394,7 +394,7 @@ Then in `myobject.h` make your wrapper inherit from `node::ObjectWrap`:
394394

395395
#endif
396396

397-
And in `myobject.cc` implement the various methods that you want to expose.
397+
And in `myobject.cc`, implement the various methods that you want to expose.
398398
Here we expose the method `plusOne` by adding it to the constructor's
399399
prototype:
400400

@@ -480,7 +480,8 @@ Test it with:
480480
### Factory of wrapped objects
481481

482482
This is useful when you want to be able to create native objects without
483-
explicitly instantiating them with the `new` operator in JavaScript, e.g.
483+
explicitly instantiating them with the `new` operator in JavaScript. For
484+
example:
484485

485486
var obj = addon.createObject();
486487
// instead of:
@@ -515,8 +516,9 @@ Let's register our `createObject` method in `addon.cc`:
515516

516517
} // namespace demo
517518

518-
In `myobject.h` we now introduce the static method `NewInstance` that takes
519-
care of instantiating the object (i.e. it does the job of `new` in JavaScript):
519+
In `myobject.h`, we now introduce the static method `NewInstance` that takes
520+
care of instantiating the object. In other words, it does the job of `new` in
521+
JavaScript:
520522

521523
// myobject.h
522524
#ifndef MYOBJECT_H
@@ -644,9 +646,9 @@ Test it with:
644646
### Passing wrapped objects around
645647

646648
In addition to wrapping and returning C++ objects, you can pass them around
647-
by unwrapping them with Node.js's `node::ObjectWrap::Unwrap` helper function.
648-
In the following `addon.cc` we introduce a function `add()` that can take on two
649-
`MyObject` objects:
649+
by unwrapping them with the Node.js helper function `node::ObjectWrap::Unwrap`.
650+
In the following `addon.cc`, we introduce a function `add()` that can take on
651+
two `MyObject` objects:
650652

651653
// addon.cc
652654
#include <node.h>
@@ -690,7 +692,7 @@ In the following `addon.cc` we introduce a function `add()` that can take on two
690692

691693
} // namespace demo
692694

693-
To make things interesting we introduce a public method in `myobject.h` so we
695+
To make things interesting, we introduce a public method in `myobject.h` so we
694696
can probe private values after unwrapping the object:
695697

696698
// myobject.h
@@ -721,7 +723,7 @@ can probe private values after unwrapping the object:
721723

722724
#endif
723725

724-
The implementation of `myobject.cc` is similar as before:
726+
The implementation of `myobject.cc` is similar to before:
725727

726728
// myobject.cc
727729
#include <node.h>
@@ -804,10 +806,10 @@ Test it with:
804806
* `callback`: `void (*)(void*)` - A pointer to the function to call at exit.
805807
* `args`: `void*` - A pointer to pass to the callback at exit.
806808

807-
Registers exit hooks that run after the event loop has ended, but before the VM
809+
Registers exit hooks that run after the event loop has ended but before the VM
808810
is killed.
809811

810-
Callbacks are run in last-in, first-out order. AtExit takes two parameters:
812+
Callbacks are run in last-in first-out order. AtExit takes two parameters:
811813
a pointer to a callback function to run at exit, and a pointer to untyped
812814
context data to be passed to that callback.
813815

0 commit comments

Comments
 (0)