Fix minor typos in text and code examples (#76)

book/src/move-basics/ownership-and-scope.md

@@ -85,7 +85,7 @@ module book::ownership {
 
 ## Scopes with Blocks
 
-Function has a main scope, and it can also have sub-scopes via the use of blocks. A block is a
+Each function has a main scope, and it can also have sub-scopes via the use of blocks. A block is a
 sequence of statements and expressions, and it has its own scope. Variables defined in a block are
 owned by this block, and when the block ends, the variables are dropped.
 

book/src/move-basics/string.md

@@ -6,7 +6,7 @@ module defines a `String` type and methods for UTF-8 encoded strings, and the se
 `std::ascii`, provides an ASCII `String` type and its methods.
 
 > Sui execution environment automatically converts bytevector into `String` in transaction inputs.
-> So in many cases, String does not to be constructed in the
+> So in many cases, a String does not need to be constructed in the
 > [Transaction Block](./../concepts/what-is-a-transaction.md).
 
 <!--

book/src/move-basics/testing.md

@@ -8,7 +8,7 @@ code.
 
 Tests in Move are functions marked with the `#[test]` attribute. This attribute tells the compiler
 that the function is a test function, and it should be run when the tests are executed. Test
-functions are regular functions, but they must take no any arguments and have no return value. They
+functions are regular functions, but they must take no arguments and have no return value. They
 are excluded from the bytecode, and are never published.
 
 ```move
@@ -62,7 +62,7 @@ abort, the test will also fail.
 ```move
 module book::testing_failure {
 
-    const EInvalidArgument: u64 = 0;
+    const EInvalidArgument: u64 = 1;
 
     #[test]
     #[expected_failure(abort_code = 0)]
@@ -73,7 +73,7 @@ module book::testing_failure {
     // attributes can be grouped together
     #[test, expected_failure(abort_code = EInvalidArgument)]
     fun test_fail_1() {
-        abort 1 // aborts with 0
+        abort 1 // aborts with 1
     }
 }
 ```

book/src/programmability/dynamic-fields.md

@@ -95,7 +95,7 @@ fields are still stored in the blockchain, but they will never become accessible
 ```
 
 Orphaned objects are not a subject to storage rebate, and the storage fees will remain unclaimed.
-One way to avoid orphaned dynamic fields during unpacking on an object is to return the `UID` and
+One way to avoid orphaned dynamic fields during unpacking of an object is to return the `UID` and
 store it somewhere temporarily until the dynamic fields are removed and handled properly.
 
 ## Custom Type as a Field Name

book/src/programmability/epoch-and-time.md

@@ -34,7 +34,7 @@ updated during checkpoints by the system, which stores the current time in milli
 Unix Epoch. The `Clock` object is defined in the `sui::clock` module and has a reserved address
 `0x6`.
 
-Clock is a shared object, but it a transaction attempting to access it mutably will fail. This
+Clock is a shared object, but a transaction attempting to access it mutably will fail. This
 limitation allows parallel access to the `Clock` object, which is important for maintaining
 performance.
 

book/src/storage/storage-functions.md

@@ -74,7 +74,7 @@ module book::transfer_to_sender {
     /// A struct with `key` is an object. The first field is `id: UID`!
     public struct AdminCap has key { id: UID }
 
-    /// Init function is a special function that is called when the module
+    /// `init` function is a special function that is called when the module
     /// is published. It is a good place to create application objects.
     fun init(ctx: &mut TxContext) {
         // Create a new `AdminCap` object, in this scope.
@@ -138,7 +138,7 @@ A quick recap:
 
 ## Freeze
 
-The `transfer::freeze` function is public function used to put an object into an _immutable_ state.
+The `transfer::freeze_object` function is public function used to put an object into an _immutable_ state.
 Once an object is _frozen_, it can never be changed, and it can be accessed by anyone by immutable
 reference.
 
@@ -210,13 +210,13 @@ public fun delete_config(c: Config) {
 
 To summarize:
 
-- `freeze_object` function is used to put an object into an _immutable_ state;
+- `transfer::freeze_object` function is used to put an object into an _immutable_ state;
 - Once an object is _frozen_, it can never be changed, deleted or transferred, and it can be
   accessed by anyone by immutable reference;
 
 ## Owned -> Frozen
 
-Since the `transfer::freeze` signature accepts any type with the `key` ability, it can take an
+Since the `transfer::freeze_object` signature accepts any type with the `key` ability, it can take an
 object that was created in the same scope, but it can also take an object that was owned by an
 account. This means that the `freeze_object` function can be used to _freeze_ an object that was
 _transferred_ to the sender. For security concerns, we would not want to freeze the `AdminCap`
@@ -234,7 +234,7 @@ public fun freeze_gift(gift: Gift) {
 
 ## Share
 
-The `transfer::share` function is a public function used to put an object into a _shared_ state.
+The `transfer::share_object` function is a public function used to put an object into a _shared_ state.
 Once an object is _shared_, it can be accessed by anyone by a mutable reference (hence, immutable
 too). The function signature is as follows, only accepts a type with the
 [`key` ability](./key-ability.md):
@@ -278,7 +278,7 @@ public fun delete_config(c: Config) {
 }
 ```
 
-The `delete_config` function takes the `Config` object by value and deletes it, and Sui Verifier
+The `delete_config` function takes the `Config` object by value and deletes it, and the Sui Verifier
 would allow this call. However, if the function returned the `Config` object back or attempted to
 `freeze` or `transfer` it, the Sui Verifier would reject the transaction.
 

book/src/storage/transfer-restrictions.md

@@ -38,7 +38,7 @@ ObjectK with `key` and ObjectKS with `key + store` abilities, and module B tries
 /// Defines `ObjectK` and `ObjectKS` with `key` and `key + store`
 /// abilities respectively
 module book::transfer_a {
-    public struct ObjectX has key { id: UID }
+    public struct ObjectK has key { id: UID }
     public struct ObjectKS has key, store { id: UID }
 }
 
@@ -48,7 +48,7 @@ module book::transfer_b {
     // types are not internal to this module
     use book::transfer_a::{ObjectK, ObjectKS};
 
-    // Fails! ObjectX is not `store`, and ObjectX is not internal to this module
+    // Fails! ObjectK is not `store`, and ObjectK is not internal to this module
     public fun transfer_k(k: ObjectK, to: address) {
         sui::transfer::transfer(k, to);
     }
@@ -72,10 +72,10 @@ module book::transfer_b {
 
 To expand on the example above:
 
-- [ ] `transfer_x` fails because ObjectK is not internal to module `transfer_b`
-- [ ] `transfer_y` fails because ObjectKS is not internal to module `transfer_b`
-- [ ] `public_transfer_x` fails because ObjectK does not have the `store` ability
-- [x] `public_transfer_y` works because ObjectKS has the `store` ability and the transfer is public
+- [ ] `transfer_k` fails because ObjectK is not internal to module `transfer_b`
+- [ ] `transfer_ks` fails because ObjectKS is not internal to module `transfer_b`
+- [ ] `public_transfer_k` fails because ObjectK does not have the `store` ability
+- [x] `public_transfer_ks` works because ObjectKS has the `store` ability and the transfer is public
 
 ## Implications of `store`
 

book/src/storage/uid-and-id.md

@@ -70,7 +70,7 @@ The ability to return the UID of an object may be utilized in pattern called _pr
 is a rarely used technique, but it may be useful in some cases, for example, the creator or an
 application may incentivize the deletion of an object by exchanging the deleted IDs for some reward.
 
-In framework development this method could be used ignore / bypass certain restrictions on "taking"
+In framework development this method could be used to ignore / bypass certain restrictions on "taking"
 the object. If there's a container that enforces certain logic on transfers, like Kiosk does, there
 could be a special scenario of skipping the checks by providing a proof of deletion.