Is this way of simplifying imports correct?

Support Contracts
1

Hi, instead of writing import statements like this:

import { ERC20 } from "@openzeppelin/contracts/token/ERC20/ERC20.sol";
import { ERC20Burnable } from "@openzeppelin/contracts/token/ERC20/extensions/ERC20Burnable.sol";
import { ERC20Permit } from "@openzeppelin/contracts/token/ERC20/extensions/draft-ERC20Permit.sol";
import { ERC20Votes } from "@openzeppelin/contracts/token/ERC20/extensions/ERC20Votes.sol";
import { Ownable } from "@openzeppelin/contracts/access/Ownable.sol";

contract MyToken is ERC20, ERC20Burnable, Ownable, ERC20Permit, ERC20Votes {

I decided to simplify it like this:

import { ERC20, ERC20Burnable } from "@openzeppelin/contracts/token/ERC20/extensions/ERC20Burnable.sol";
import { ERC20Votes, ERC20Permit } from "@openzeppelin/contracts/token/ERC20/extensions/ERC20Votes.sol";
import { Ownable } from "@openzeppelin/contracts/access/Ownable.sol";

contract MyToken is ERC20Burnable, Ownable, ERC20Votes {

My questions are:

  1. Is it okay to do it like this, or does this cause some unwanted consequences?
  2. AFAIK the order of placing extensions matters. In my case I put the ERC20Votes in the last place (is ERC20Burnable, Ownable, ERC20Votes). Is that correct? Or should it be placed somewhere else, for example in the first place (is ERC20Votes, ERC20Burnable, Ownable)?

Thanks!

2

Hello @tempe-techie,

At first sight, it's difficult to tell if there are unexpected consequences on your smart contract. This is basically because of the way Solidity linearizes the inheritance graph based on the order you defined the inherited contracts.

I recommend you going through the Multiple Inheritance and Linearization section of the Solidity docs.

The TLDR is that the order of execution of functions implemented by multiple inherited contracts will follow a right-to-left order in the contract declaration (contract Foo is <Leftmost>, ..., <Rightmost>), so as long as you don't have to disambiguate between functions using function Bar() ... override(A, B), both options you presented are likely to be equivalent.

Hope this helps!

1 Like