Skip to content

docs: fix ERC165 docs and ERC165Checker references #6076

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: typo-fixes
Choose a base branch
from
+11 −9
Open

docs: fix ERC165 docs and ERC165Checker references #6076

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
20 changes: 11 additions & 9 deletions docs/modules/ROOT/pages/utilities.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -46,7 +46,7 @@ function _verify(
bytes32 s,
bytes32 qx,
bytes32 qy
) internal pure returns (bool) {
) internal view returns (bool) {
return data.verify(data, r, s, qx, qy);
}
----
Expand All @@ -63,7 +63,7 @@ function _verify(
bytes32 s,
bytes32 qx,
bytes32 qy
) internal pure returns (bool) {
) internal view returns (bool) {
// Will only call the precompile at address(0x100)
return data.verifyNative(data, r, s, qx, qy);
}
Expand Down Expand Up @@ -191,11 +191,13 @@ For an on-chain Merkle Tree, see the xref:api:utils.adoc#MerkleTree[`MerkleTree`
In Solidity, it's frequently helpful to know whether or not a contract supports an interface you'd like to use. ERC-165 is a standard that enables runtime interface detection. Contracts provide helpers both for implementing ERC-165 in your contracts and querying other contracts:

* xref:api:utils.adoc#IERC165[`IERC165`] — this is the ERC-165 interface that defines xref:api:utils.adoc#IERC165-supportsInterface-bytes4-[`supportsInterface`]. When implementing ERC-165, you'll conform to this interface.
* xref:api:utils.adoc#ERC165[`ERC165`] — inherit this contract if you'd like to support interface detection using a lookup table in contract storage. You can register interfaces using xref:api:utils.adoc#ERC165-_registerInterface-bytes4-[`_registerInterface(bytes4)`]: check out example usage as part of the ERC-721 implementation.
* xref:api:utils.adoc#ERC165[`ERC165`] — inherit this contract and override `supportsInterface(bytes4)`; chain `super.supportsInterface(interfaceId)` when multiple parents are involved.
* xref:api:utils.adoc#ERC165Checker[`ERC165Checker`] — ERC165Checker simplifies the process of checking whether or not a contract supports an interface you care about.
* include with `using ERC165Checker for address;`
* xref:api:utils.adoc#ERC165Checker-_supportsInterface-address-bytes4-[`myAddress._supportsInterface(bytes4)`]
* xref:api:utils.adoc#ERC165Checker-_supportsAllInterfaces-address-bytes4---[`myAddress._supportsAllInterfaces(bytes4[\])`]
* xref:api:utils.adoc#ERC165Checker-supportsInterface-address-bytes4-[`myAddress.supportsInterface(bytes4)`]
* xref:api:utils.adoc#ERC165Checker-supportsAllInterfaces-address-bytes4---[`myAddress.supportsAllInterfaces(bytes4[\])`]
* xref:api:utils.adoc#ERC165Checker-supportsERC165-address-[`myAddress.supportsERC165()`]
* xref:api:utils.adoc#ERC165Checker-getSupportedInterfaces-address-bytes4---[`ERC165Checker.getSupportedInterfaces(myAddress, ids)`]

[source,solidity]
----
Expand Down Expand Up @@ -255,7 +257,7 @@ TIP: While working with different data types that might require casting, you can
[[structures]]
== Structures

Some use cases require more powerful data structures than arrays and mappings offered natively in Solidity. Contracts provides these libraries for enhanced data structure management:
Some use cases require more powerful data structures than arrays and mappings offered natively in Solidity. Contracts provide these libraries for enhanced data structure management:

- xref:api:utils.adoc#BitMaps[`BitMaps`]: Store packed booleans in storage.
- xref:api:utils.adoc#Checkpoints[`Checkpoints`]: Checkpoint values with built-in lookups.
Expand Down Expand Up @@ -292,7 +294,7 @@ function push(bytes32 leaf) public /* onlyOwner */ {

The library also supports custom hashing functions, which can be passed as an extra parameter to the xref:api:utils.adoc#MerkleTree-push-struct-MerkleTree-Bytes32PushTree-bytes32-[`push`] and xref:api:utils.adoc#MerkleTree-setup-struct-MerkleTree-Bytes32PushTree-uint8-bytes32-[`setup`] functions.

Using custom hashing functions is a sensitive operation. After setup, it requires to keep using the same hashing function for every new value pushed to the tree to avoid corrupting the tree. For this reason, it's a good practice to keep your hashing function static in your implementation contract as follows:
Using custom hashing functions is a sensitive operation. After setup, it requires continuing to use the same hashing function for every new value pushed to the tree to avoid corrupting the tree. For this reason, it's a good practice to keep your hashing function static in your implementation contract as follows:

[source,solidity]
----
Expand Down Expand Up @@ -346,9 +348,9 @@ function replace(Uint256Heap storage self, uint256 newValue) internal returns (u

=== Packing

The storage in the EVM is shaped in chunks of 32 bytes, each of this chunks is known as a _slot_, and can hold multiple values together as long as these values don't exceed its size. These properties of the storage allow for a technique known as _packing_, that consists of placing values together on a single storage slot to reduce the costs associated to reading and writing to multiple slots instead of just one.
The storage in the EVM is shaped in chunks of 32 bytes, each of these chunks is known as a _slot_, and can hold multiple values together as long as these values don't exceed its size. These properties of the storage allow for a technique known as _packing_, that consists of placing values together on a single storage slot to reduce the costs associated to reading and writing to multiple slots instead of just one.

Commonly, developers pack values using structs that place values together so they fit better in storage. However, this approach requires to load such struct from either calldata or memory. Although sometimes necessary, it may be useful to pack values in a single slot and treat it as a packed value without involving calldata or memory.
Commonly, developers pack values using structs that place values together so they fit better in storage. However, this approach requires loading such struct from either calldata or memory. Although sometimes necessary, it may be useful to pack values in a single slot and treat it as a packed value without involving calldata or memory.

The xref:api:utils.adoc#Packing[`Packing`] library is a set of utilities for packing values that fit in 32 bytes. The library includes 3 main functionalities:

Expand Down
Loading