Merge pull request #75 from StevenMia/main

chore: fix some typos in comments

unit-five/lessons/1_programmable_transaction_block.md

@@ -1,6 +1,6 @@
 # Programmable Transaction Block (PTB)
 
-Before we get into **Sui Kiosk**, it's neccessary to learn about Programmable Transaction Block (PTB) and how it helps us to seamlessly fulfill Kiosk usage flow
+Before we get into **Sui Kiosk**, it's necessary to learn about Programmable Transaction Block (PTB) and how it helps us to seamlessly fulfill Kiosk usage flow
 
 ## Introduction
 
@@ -16,7 +16,7 @@ PTB is a built-in feature and supported natively by Sui Network and Sui VM. On S
 - Each PTB is composed of multiple individual commands chaining together in order. One command that we will use most of the time is `MoveCall`. For other commands, please refer to the [documentation here](https://docs.sui.io/concepts/transactions/prog-txn-blocks#executing-a-transaction-command).
 - When the transaction is executed, the commands are executed in the order they are defined when building the PTB. The outputs of one transaction command can be used as inputs for any subsequent commands.
 - Sui guarantees the atomicity of a PTB by applying the effects of all commands in the transaction (block) at the end of the transaction. If one command fails, the entire block fails and effects will not take place.
-- Each PTB can hold up to 1024 unique operations. This allows cheaper gas fee and faster execution compared to executng 1024 individual transactions in other traditional blockchains.
+- Each PTB can hold up to 1024 unique operations. This allows cheaper gas fee and faster execution compared to executing 1024 individual transactions in other traditional blockchains.
 - If the output returned by one command is non-`drop` value. It must be consumed by subsequent commands within the same PTB. Otherwise, the transaction (block) is considered to be failed.
 
 *💡Note: Refer to [documentation here](https://docs.sui.io/concepts/transactions/prog-txn-blocks) for full details on PTB*

unit-five/lessons/4_kiosk_basic_usage.md

@@ -35,7 +35,7 @@ export KIOSK=<Object id of newly created Kiosk>
 export KIOSK_OWNER_CAP=<Object id of newly created KioskOwnerCap>
 ```
 
-_💡Note: Kiosk is heterogenous collection by default so that's why it doesn't need type parameter for their items_
+_💡Note: Kiosk is heterogeneous collection by default so that's why it doesn't need type parameter for their items_
 
 ## Place Item inside Kiosk
 

unit-five/lessons/5_transfer_policy.md

@@ -79,7 +79,7 @@ module kiosk::fixed_royalty_rule {
 }
 ```
 
-`Rule` represents a witness type to add to `TransferPolicy`, it helps to identify and distinguish between multiple rules adding to one policy. `Config` is the configuration of the `Rule`, as we implement fixed royaltee fee, the settings should include the percentage we want to deduct out of orignal payment.
+`Rule` represents a witness type to add to `TransferPolicy`, it helps to identify and distinguish between multiple rules adding to one policy. `Config` is the configuration of the `Rule`, as we implement fixed royaltee fee, the settings should include the percentage we want to deduct out of original payment.
 
 #### Add Rule to TransferPolicy
 
@@ -141,7 +141,7 @@ public fun fee_amount<T: key + store>(policy: &TransferPolicy<T>, paid: u64): u6
 
 We need a helper `fee_amount()` to calculate the royalty fee given the policy and the payment amount. We use `transfer_policy::get_rule()` to enquire the configuration and use it for fee calculation.
 
-`pay()` is a function that users must call themselves to fullfil the `TransferRequest` (described in the next section) before `transfer_policy::confirm_request()`. `transfer_policy::paid()` gives us original payment of the trade represented by `TransferRequest`. After royalty fee calculation, we will add the fee to the policy through `transfer_policy::add_to_balance()`, any fee collected by the policy is accumulated here and `TransferPolicyCap` owner can withdraw later. Last but not least, we use `transfer_policy::add_receipt()` to flag the `TransferRequest` that this rule is passed and ready to be confirmed with `transfer_policy::confirm_request()`.
+`pay()` is a function that users must call themselves to fulfill the `TransferRequest` (described in the next section) before `transfer_policy::confirm_request()`. `transfer_policy::paid()` gives us original payment of the trade represented by `TransferRequest`. After royalty fee calculation, we will add the fee to the policy through `transfer_policy::add_to_balance()`, any fee collected by the policy is accumulated here and `TransferPolicyCap` owner can withdraw later. Last but not least, we use `transfer_policy::add_receipt()` to flag the `TransferRequest` that this rule is passed and ready to be confirmed with `transfer_policy::confirm_request()`.
 
 ## Buy Item from Kiosk
 
@@ -174,7 +174,7 @@ Recall from the previous section, the item must be placed inside the kiosk, then
 export KIOSK_TSHIRT=<Object ID of the listed TShirt>
 ```
 
-Let's build a PTB to execute a trade. The flow is straightforward, we buy the listed item from the kiosk, the item and `TransferRequest` is returned, then, we call `fixed_royalty_fee::pay` to fullfil the `TransferRequest`, we confirm the `TransferRequest` with `confirm_request()` before finally transfer the item to the buyer.
+Let's build a PTB to execute a trade. The flow is straightforward, we buy the listed item from the kiosk, the item and `TransferRequest` is returned, then, we call `fixed_royalty_fee::pay` to fulfill the `TransferRequest`, we confirm the `TransferRequest` with `confirm_request()` before finally transfer the item to the buyer.
 ```bash
 sui client ptb \
 --assign price 10000 \

unit-three/lessons/2_intro_to_generics.md

@@ -45,7 +45,7 @@ module  generics::storage {
 
 💡It's important to note here that the inner type `T` in the above example must meet certain ability constraints due to the outer container type. In this example, `T` must have `store`, as `Box` has `store` and `key`. However, `T` can also have abilities that the container doesn't have, such as `drop` in this example.
 
-The intuition is that if the container is allowed to contain a type that does not follow the same rules that it does, the container would violate its own ability. How can a box be storeable if its content isn't also storeable?
+The intuition is that if the container is allowed to contain a type that does not follow the same rules that it does, the container would violate its own ability. How can a box be storable if its content isn't also storable?
 
 We will see in the next section that there is a way to get around this rule in certain cases using a special keyword, called `phantom`.