feat: rename method call to function call (#1719)

docs/1.concepts/web3/near.md

@@ -104,7 +104,7 @@ Throughout this section, we’ve discussed how to call a smart contract from a c
 
 Looks simple enough, but there are few gotchas:
 - In order to provide a call status (success or failure) and a return value to the calling contract, a callback method should be called, so there’s no single activation of ContractA. Instead, an entry method is called first by the user, and then a callback is invoked in response to cross-contract call completion.
-- Transaction status is determined by the success or failure of a first method call. For example, if a ContractB.methodB or ContractA.methodACb call fails, the transaction will still be considered successful. This means that to ensure proper rollbacks in case of expected failures, custom rollback code must be written in the ContractA.methodACb, and the callback method itself must not fail at all. Otherwise, smart contract state might be left inconsistent.
+- Transaction status is determined by the success or failure of a first function call. For example, if a ContractB.methodB or ContractA.methodACb call fails, the transaction will still be considered successful. This means that to ensure proper rollbacks in case of expected failures, custom rollback code must be written in the ContractA.methodACb, and the callback method itself must not fail at all. Otherwise, smart contract state might be left inconsistent.
 - Cross-contract calls must have gas attached by the calling contract. Total available gas is attached to a transaction by a calling user, and distributed inside the call chain by contracts. For example, if 15TGas are attached by the user, ContractA may reserve 5TGas for itself and pass the rest to ContractB. All unspent gas will be refunded back to the user.
 
 

docs/2.develop/contracts/serialization.md

@@ -12,7 +12,7 @@ from their complex representation into simpler ones.
 This process of translating **complex objects into simpler single-value** representations is called
 **serialization**. NEAR uses two serialization formats: [JSON](https://www.json.org/json-en.html) and
 [Borsh](https://borsh.io/).
-1. [JSON](https://www.json.org/json-en.html) is used to serialize the contract's input/output during a method call
+1. [JSON](https://www.json.org/json-en.html) is used to serialize the contract's input/output during a function call
 2. [Borsh](https://borsh.io/) is used to serialize the contract's state.
 
 ---

docs/2.develop/integrate/frontend.md

@@ -278,7 +278,7 @@ function formatAmount(amount) {
 NEAR API JS does not limit itself to simply calling methods in a contract. In fact, you can use it to transform your web-app into a rich user experience. While we will not cover these topics in depth, it is important for you to know that with NEAR API JS you can also:
 
 - **[Sign and verify messages](https://github.com/near/near-api-js/blob/master/packages/cookbook/utils/verify-signature.js)**: this is very useful to prove that a message was created by the user.
-- **[Create batch transactions](https://github.com/near/near-api-js/tree/master/packages/cookbook/transactions/batch-transactions.js)**: this enables to link multiple [actions](/develop/contracts/actions) (e.g. multiple method calls). If one of the transactions fails, then they are all reverted.
+- **[Create batch transactions](https://github.com/near/near-api-js/tree/master/packages/cookbook/transactions/batch-transactions.js)**: this enables to link multiple [actions](/develop/contracts/actions) (e.g. multiple function calls). If one of the transactions fails, then they are all reverted.
 - **[Create accounts](https://github.com/near/near-api-js/tree/master/packages/cookbook/accounts/create-testnet-account.js)**: deploy accounts for your users!
 
 Check the [cookbook](/tools/near-api-js/cookbook) to learn how to supercharge your webapp.

docs/2.develop/relevant-contracts/ft.md

@@ -125,7 +125,7 @@ In order to send a fungible token to an account, both the sender and receiver mu
 <hr className="subsection"/>
 
 ## Attaching FTs to a Call
-Natively, only NEAR tokens (Ⓝ) can be attached to a method calls. However, the FT standard enables to attach fungible tokens in a call by using the FT-contract as intermediary. This means that, instead of you attaching tokens directly to the call, you ask the FT-contract to do both a transfer and a method call in your name.
+Natively, only NEAR tokens (Ⓝ) can be attached to a function calls. However, the FT standard enables to attach fungible tokens in a call by using the FT-contract as intermediary. This means that, instead of you attaching tokens directly to the call, you ask the FT-contract to do both a transfer and a function call in your name.
 
 <Tabs className="language-tabs" groupId="code-tabs">
   <TabItem value="cli" label="NEAR CLI">

docs/2.develop/relevant-contracts/nft.md

@@ -116,7 +116,7 @@ Implement [events](https://nomicon.io/Standards/Tokens/NonFungibleToken/Event) t
 <hr className="subsection"/>
 
 ## Attaching NFTs to a Call
-Natively, only NEAR tokens (Ⓝ) can be attached to a method calls. However, the NFT standard enables to attach a non-fungible tokens in a call by using the NFT-contract as intermediary. This means that, instead of you attaching tokens directly to the call, you ask the NFT-contract to do both a transfer and a method call in your name.
+Natively, only NEAR tokens (Ⓝ) can be attached to a function calls. However, the NFT standard enables to attach a non-fungible tokens in a call by using the NFT-contract as intermediary. This means that, instead of you attaching tokens directly to the call, you ask the NFT-contract to do both a transfer and a function call in your name.
 
 <Tabs className="language-tabs" groupId="code-tabs">
   <TabItem value="cli" label="NEAR CLI">

docs/3.tutorials/examples/advanced-xcc.md

@@ -7,7 +7,7 @@ import TabItem from '@theme/TabItem';
 import {CodeTabs, Language, Github} from "@site/src/components/codetabs"
 
 This example presents 3 instances of complex cross-contract calls. Particularly, it shows:
-1. How to batch multiple method calls to a same contract.
+1. How to batch multiple function calls to a same contract.
 2. How to call multiple contracts in parallel, each returning a different type.
 3. Different ways of handling the responses in the callback.
 

docs/3.tutorials/fts/3-circulating-supply.md

@@ -47,7 +47,7 @@ src
   └── storage.rs
 ```
 
-In the `internal.rs` file, add the following code to create a method called `internal_deposit` which takes an `AccountId` and a `Balance` and adds the amount to the account's current supply of FTs. 
+In the `internal.rs` file, add the following code to create a function called `internal_deposit` which takes an `AccountId` and a `Balance` and adds the amount to the account's current supply of FTs. 
 
 <Github language="rust" start="1" end="18" url="https://github.com/near-examples/ft-tutorial/blob/main/3.initial-supply/src/internal.rs" />
 

docs/3.tutorials/fts/5.transfers.md

@@ -36,7 +36,7 @@ You'll start by implementing the `ft_transfer` logic which is found in the `src/
 
 There are a couple things to notice here. 
 
-1. We've introduced a new method called `assert_one_yocto()`. This method will ensure that the user is signing the transaction with a full access key by requiring a deposit of exactly 1 yoctoNEAR, the smallest possible amount of $NEAR that can be transferred. Since the transfer function is potentially transferring very valuable assets, you'll want to make sure that whoever is calling the function has a full access key.
+1. We've introduced a new function called `assert_one_yocto()`. This method will ensure that the user is signing the transaction with a full access key by requiring a deposit of exactly 1 yoctoNEAR, the smallest possible amount of $NEAR that can be transferred. Since the transfer function is potentially transferring very valuable assets, you'll want to make sure that whoever is calling the function has a full access key.
 
 2. We've introduced an `internal_transfer` method. This will perform all the logic necessary to transfer the tokens internally.
 

docs/3.tutorials/nfts/4-core.md

@@ -53,7 +53,7 @@ You'll start by implementing the `nft_transfer` logic. This function will transf
 
 <Github language="rust" start="62" end="82" url="https://github.com/near-examples/nft-tutorial/blob/4.core/nft-contract/src/nft_core.rs" />
 
-There are a couple things to notice here. Firstly, we've introduced a new method called `assert_one_yocto()`. This method will ensure that the user has attached exactly one yoctoNEAR to the call. If a function requires a deposit, you need a full access key to sign that transaction. By adding the one yoctoNEAR deposit requirement, you're essentially forcing the user to sign the transaction with a full access key.
+There are a couple things to notice here. Firstly, we've introduced a new function called `assert_one_yocto()`. This method will ensure that the user has attached exactly one yoctoNEAR to the call. If a function requires a deposit, you need a full access key to sign that transaction. By adding the one yoctoNEAR deposit requirement, you're essentially forcing the user to sign the transaction with a full access key.
 
 Since the transfer function is potentially transferring very valuable assets, you'll want to make sure that whoever is calling the function has a full access key.
 

docs/3.tutorials/nfts/js/4-core.md

@@ -60,7 +60,7 @@ You'll start by implementing the `nft_transfer` logic. This function will transf
 
 <Github language="js" start="37" end="64" url="https://github.com/near-examples/nft-tutorial-js/blob/4.core/src/nft-contract/nft_core.ts" />
 
-There are a couple things to notice here. Firstly, we've introduced a new method called `assertOneYocto()`. This method will ensure that the user has attached exactly one yoctoNEAR to the call. If a function requires a deposit, you need a full access key to sign that transaction. By adding the one yoctoNEAR deposit requirement, you're essentially forcing the user to sign the transaction with a full access key.
+There are a couple things to notice here. Firstly, we've introduced a new function called `assertOneYocto()`. This method will ensure that the user has attached exactly one yoctoNEAR to the call. If a function requires a deposit, you need a full access key to sign that transaction. By adding the one yoctoNEAR deposit requirement, you're essentially forcing the user to sign the transaction with a full access key.
 
 Since the transfer function is potentially transferring very valuable assets, you'll want to make sure that whoever is calling the function has a full access key.
 

docs/5.api/rpc/contracts.md

@@ -1585,7 +1585,7 @@ Here is the exhaustive list of the error variants that can be returned by `call_
     </tr>
     <tr>
       <td>CONTRACT_EXECUTION_ERROR</td>
-      <td>The execution of the view method call failed (crashed, run out of the default 200 TGas limit, etc)</td>
+      <td>The execution of the view function call failed (crashed, run out of the default 200 TGas limit, etc)</td>
       <td>
         <ul>
           <li>Check <code>error.cause.info</code> for more details</li>

docs/7.primitives/ft.md

@@ -165,7 +165,7 @@ To send FT to another account you will use the `ft_transfer` method, indicating
 ---
 
 ## Attaching FTs to a Call
-Natively, only NEAR tokens (Ⓝ) can be attached to a method calls. However, the FT standard enables to attach fungible tokens in a call by using the FT-contract as intermediary. This means that, instead of you attaching tokens directly to the call, you ask the FT-contract to do both a transfer and a method call in your name.
+Natively, only NEAR tokens (Ⓝ) can be attached to a function calls. However, the FT standard enables to attach fungible tokens in a call by using the FT-contract as intermediary. This means that, instead of you attaching tokens directly to the call, you ask the FT-contract to do both a transfer and a function call in your name.
 
 Let's assume that you need to deposit FTs on Ref Finance.
 

docs/7.primitives/nft.md

@@ -156,7 +156,7 @@ In both cases, it is necessary to invoke the `nft_transfer` method, indicating t
 ---
 
 ## Attaching NFTs to a Call
-Natively, only NEAR tokens (Ⓝ) can be attached to a method calls. However, the NFT standard enables to attach a non-fungible tokens in a call by using the NFT-contract as intermediary. This means that, instead of you attaching tokens directly to the call, you ask the NFT-contract to do both a transfer and a method call in your name.
+Natively, only NEAR tokens (Ⓝ) can be attached to a function calls. However, the NFT standard enables to attach a non-fungible tokens in a call by using the NFT-contract as intermediary. This means that, instead of you attaching tokens directly to the call, you ask the NFT-contract to do both a transfer and a function call in your name.
 
 <Tabs className="language-tabs" groupId="code-tabs">
   <TabItem value="🖥️ CLI" label="🖥️ CLI">

docs/bos/queryapi/context.md

@@ -127,7 +127,7 @@ Except for [upsert](#upsert), all of the below methods are used in [social_feed_
 
 ### Insert
 
-This method allows inserting one or more objects into the table preceding the method call. The inserted objects are then returned back with all of their information. Later on, we may implement returning specific fields but for now, we are returning them all. This goes for all methods. 
+This method allows inserting one or more objects into the table preceding the function call. The inserted objects are then returned back with all of their information. Later on, we may implement returning specific fields but for now, we are returning them all. This goes for all methods. 
 
 #### Input
 

docs/bos/tutorial/hello-near.md

@@ -45,7 +45,7 @@ To modify the greeting, we simply need to use `Near.call` to call the `set_greet
 
 Lets create it in two steps:
 1. Build the HTML that will be rendered
-2. Add the logic to handle the method call
+2. Add the logic to handle the function call
 
 <hr className="subsection" />