s/remove/remove_or_drop/ in CanonicalABI.md

Author: lukewagner

design/mvp/CanonicalABI.md

@@ -333,11 +333,11 @@ class HandleTable:
     return i
 ```
 The `HandleTable` class maintains a dense array of handles that can contain
-holes created by the `remove` method (defined below). These holes are kept in a
-separate Python list here, but an optimizing implementation could instead store
-the free list in the free elements of `array`. When adding a new handle,
-`HandleTable` first consults the `free` list, which is popped LIFO to better
-detect use-after-free bugs in the guest code.
+holes created by the `remove_or_drop` method (defined below). These holes are
+kept in a separate Python list here, but an optimizing implementation could
+instead store the free list in the free elements of `array`. When adding a new
+handle, `HandleTable` first consults the `free` list, which is popped LIFO to
+better detect use-after-free bugs in the guest code.
 
 The `get` method is used by other `HandleTable` methods and canonical
 definitions below and uses dynamic guards to catch out-of-bounds and
@@ -349,9 +349,9 @@ use-after-free:
     return self.array[i]
 ```
 
-The last method of `HandleTable`, `remove`, is used to drop or transfer a
-handle out of the handle table. `remove` adds the removed handle to the `free`
-list for later recycling by `add` (above).
+The last method of `HandleTable`, `remove_or_drop`, is used to drop or transfer
+a handle out of the handle table. `remove_or_drop` adds the removed handle to
+the `free` list for later recycling by `add` (above).
 ```python
   def remove_or_drop(self, i, t, drop):
     h = self.get(i)
@@ -370,13 +370,13 @@ list for later recycling by `add` (above).
     return h
 ```
 The `lend_count` guard ensures that no dangling borrows are created when
-destroying a resource. Because `remove` is used for cross-component transfer
-of `own` handles (via `lift_own` below), this `lend_count` guard ensures that
-when a component receives an `own`, it receives a unique reference to the
-resource and that there aren't any dangling borrows hanging around from the
-previous owner. The bookkeeping performed by `remove` for borrowed handles
-records the fulfillment of the obligation of the borrower to drop the handle
-before the end of the call.
+destroying a resource. Because `remove_or_drop` is used for cross-component
+transfer of `own` handles (via `lift_own` below), this `lend_count` guard
+ensures that when a component receives an `own`, it receives a unique reference
+to the resource and that there aren't any dangling borrows hanging around from
+the previous owner. The bookkeeping performed by `remove_or_drop` for borrowed
+handles records the fulfillment of the obligation of the borrower to drop the
+handle before the end of the call.
 
 Finally, we can define `HandleTables` (plural) as simply a wrapper around
 a mutable mapping from `ResourceType` to `HandleTable`:
@@ -405,8 +405,8 @@ While this Python code performs a dynamic hash-table lookup on each handle
 table access, as we'll see below, the `rt` parameter is always statically
 known such that a normal implementation can statically enumerate all
 `HandleTable` objects at compile time and then route the calls to `add`,
-`get` and `remove` to the correct `HandleTable` at the callsite. The net
-result is that each component instance will contain one handle table per
+`get` and `remove_or_drop` to the correct `HandleTable` at the callsite. The
+net result is that each component instance will contain one handle table per
 resource type used by the component, with each compiled adapter function
 accessing the correct handle table as-if it were a global variable.