Clarification

Author: eggyal

text/000-prototypal-inheritance.md

@@ -210,9 +210,9 @@ Two issues do however arise, regarding the internal pointers these shim objects
 
 ### FFI polymorphism
 
-*All* objects are to be instantiated from JavaScript, irrespective of whether their type is actually exported from WASM.
+JS shim'd WASM objects are to be *instantiated* from JavaScript.
 
-This means that instantiating a struct defined in Rust would *always* entail using JavaScript's [`new`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/new) operator on the shim class, irrespective of whether the object is being instantiated from within JavaScript or WASM (if the latter, there must necessarily be a call to an imported function in order to trigger such behaviour; the result would therefore produce a wrapped `JsValue` that indirectly represents the instantiated WASM-native object: this wrapper should be a [smart pointer](https://doc.rust-lang.org/book/ch15-00-smart-pointers.html), implementing [`std::ops::Deref`](https://doc.rust-lang.org/std/ops/trait.Deref.html) for the underlying struct in a manner that avoids FFI roundtrips in order to obtain the boxed `WasmRefCell`).
+This means that instantiating an exported WASM type would *always* entail using JavaScript's [`new`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/new) operator on the shim class, irrespective of whether the object is being instantiated from within JavaScript or WASM (if the latter, there must necessarily be a call to an imported function in order to trigger such behaviour; the result would therefore produce a wrapped `JsValue` that indirectly represents the instantiated WASM-native object: this wrapper should be a [smart pointer](https://doc.rust-lang.org/book/ch15-00-smart-pointers.html), implementing [`std::ops::Deref`](https://doc.rust-lang.org/std/ops/trait.Deref.html) for the underlying struct in a manner that avoids FFI roundtrips in order to obtain the boxed `WasmRefCell`).
 
 Accordingly, not only would the associated JavaScript shim objects always be properly instantiated (with both the correct prototype chains and also the correct sequence of superconstructor calls), but furthermore any transfer of such objects over the FFI (from JavaScript to WASM) would reference the correct WASM object from their prototype chain (via the namespacing of the internal pointers described above)—thereby achieving instant polymorphism of such objects to parent types when they are sent back over the FFI.