Rust specific terminology replaced with JS one

examples/src/standard-ft/my-ft.ts

@@ -30,16 +30,6 @@ class FTPrefix implements IntoStorageKey {
     }
 }
 
-/** Implementation of a FungibleToken standard
- * Allows to include NEP-141 compatible token to any contract.
- * There are next traits that any contract may implement:
- *     - FungibleTokenCore -- interface with ft_transfer methods. FungibleToken provides methods for it.
- *     - FungibleTokenMetaData -- return metadata for the token in NEP-148, up to contract to implement.
- *     - StorageManager -- interface for NEP-145 for allocating storage per account. FungibleToken provides methods for it.
- *     - AccountRegistrar -- interface for an account to register and unregister
- *
- * For example usage, see examples/fungible-token/src/lib.rs.
- */
 @NearBindgen({ requireInit: true })
 export class MyFt implements FungibleTokenCore, StorageManagement, FungibleTokenResolver {
     token: FungibleToken;
@@ -97,7 +87,6 @@ export class MyFt implements FungibleTokenCore, StorageManagement, FungibleToken
         return this.token.measure_account_storage_usage();
     }
 
-    /** Implementation of FungibleTokenCore */
     @call({ payableFunction: true })
     ft_transfer({
         receiver_id,
@@ -136,9 +125,6 @@ export class MyFt implements FungibleTokenCore, StorageManagement, FungibleToken
         return this.token.ft_balance_of({ account_id });
     }
 
-    /** Implementation of StorageManagement
-     * @param registration_only doesn't affect the implementation for vanilla fungible token.
-     */
     @call({ payableFunction: true })
     storage_deposit(
         {
@@ -152,14 +138,6 @@ export class MyFt implements FungibleTokenCore, StorageManagement, FungibleToken
         return this.token.storage_deposit({ account_id, registration_only });
     }
 
-    /**
-     * While storage_withdraw normally allows the caller to retrieve `available` balance, the basic
-     * Fungible Token implementation sets storage_balance_bounds.min == storage_balance_bounds.max,
-     * which means available balance will always be 0. So this implementation:
-     * - panics if `amount > 0`
-     * - never transfers Ⓝ to caller
-     * - returns a `storage_balance` struct if `amount` is 0
-     */
     @view({})
     storage_withdraw({ amount }: { amount?: bigint }): StorageBalance {
         return this.token.storage_withdraw({ amount });

packages/near-contract-standards/src/fungible_token/core.ts

@@ -2,7 +2,7 @@ import { AccountId, PromiseOrValue, Balance } from "near-sdk-js"
 import { Option } from "../non_fungible_token/utils"
 export interface FungibleTokenCore {
     /**
-     * Transfers positive `amount` of tokens from the `env::predecessor_account_id` to `receiver_id`.
+     * Transfers positive `amount` of tokens from the `near.predecessorAccountId()` to `receiver_id`.
      * Both accounts must be registered with the contract for transfer to succeed. (See [NEP-145](https://github.com/near/NEPs/discussions/145))
      * This method must to be able to accept attached deposits, and must not panic on attached deposit.
      * Exactly 1 yoctoNEAR must be attached.
@@ -24,7 +24,7 @@ export interface FungibleTokenCore {
     });
 
     /**
-     * Transfers positive `amount` of tokens from the `env::predecessor_account_id` to `receiver_id` account. Then
+     * Transfers positive `amount` of tokens from the `near.predecessorAccountId()` to `receiver_id` account. Then
      * calls `ft_on_transfer` method on `receiver_id` contract and attaches a callback to resolve this transfer.
      * `ft_on_transfer` method must return the amount of tokens unused by the receiver contract, the remaining tokens
      * must be refunded to the `predecessor_account_id` at the resolve transfer callback.

packages/near-contract-standards/src/fungible_token/core_impl.ts

@@ -26,13 +26,13 @@ const ERR_TOTAL_SUPPLY_OVERFLOW: string = "Total supply overflow";
 
 /** Implementation of a FungibleToken standard
  * Allows to include NEP-141 compatible token to any contract.
- * There are next traits that any contract may implement:
+ * There are next interfaces that any contract may implement:
  *     - FungibleTokenCore -- interface with ft_transfer methods. FungibleToken provides methods for it.
  *     - FungibleTokenMetaData -- return metadata for the token in NEP-148, up to contract to implement.
  *     - StorageManager -- interface for NEP-145 for allocating storage per account. FungibleToken provides methods for it.
  *     - AccountRegistrar -- interface for an account to register and unregister
  *
- * For example usage, see examples/fungible-token/src/lib.rs.
+ * For example usage, see examples/src/standard-ft/src/my-ft.ts
  */
 export class FungibleToken implements FungibleTokenCore, StorageManagement, FungibleTokenResolver {
     // AccountID -> Account balance.