Import vs Import and inherit

CryptoEatsTheWorld · November 25, 2020, 9:55pm

It occurred ot me today that there is something about imports I don’t quite get.

What is the practical difference between:

simply importing a contract in the head of your sol file, versus
importing that contract AND ALSO using the ‘is’ keyword referring to that contract in your contract declaration

And follow up questions 3 and 4 would be the same as above, but if it was an interface instead of a contract you were importing.

abcoathup · November 30, 2020, 5:22am

Hi @CryptoEatsTheWorld,

Importing imports all the global symbols from the file being imported into the current global scope.

See the Solidity documentation for details on imports:

An example of importing where you are not inheriting is using utilities such as SafeMath or Counters:

github.com

OpenZeppelin/openzeppelin-contracts/blob/v3.2.0/contracts/presets/ERC721PresetMinterPauserAutoId.sol#L28


*  - token ID and URI autogeneration
*
* This contract uses {AccessControl} to lock permissioned functions using the
* different roles - head to its documentation for details.
*
* The account that deploys the contract will be granted the minter and pauser
* roles, as well as the default admin role, which will let it grant both minter
* and pauser roles to other accounts.
*/
contract ERC721PresetMinterPauserAutoId is Context, AccessControl, ERC721Burnable, ERC721Pausable {
   using Counters for Counters.Counter;
   bytes32 public constant MINTER_ROLE = keccak256("MINTER_ROLE");
   bytes32 public constant PAUSER_ROLE = keccak256("PAUSER_ROLE");
   Counters.Counter private _tokenIdTracker;
   /**
    * @dev Grants `DEFAULT_ADMIN_ROLE`, `MINTER_ROLE` and `PAUSER_ROLE` to the
    * account that deploys the contract.
    *

is means that your contract inherits from another contract.
contract MyToken is ERC20 means that your token inherits from the OpenZeppelin Contracts ERC20 implementation.

See the Solidity documentation for details on inheritance:

Also see the OpenZeppelin Contracts documentation on extending:

An example of importing where you are inheriting is extending from ERC20Burnable and ERC20Pausable:

github.com

OpenZeppelin/openzeppelin-contracts/blob/v3.2.0/contracts/presets/ERC20PresetMinterPauser.sol#L25


*  - a minter role that allows for token minting (creation)
*  - a pauser role that allows to stop all token transfers
*
* This contract uses {AccessControl} to lock permissioned functions using the
* different roles - head to its documentation for details.
*
* The account that deploys the contract will be granted the minter and pauser
* roles, as well as the default admin role, which will let it grant both minter
* and pauser roles to other accounts.
*/
contract ERC20PresetMinterPauser is Context, AccessControl, ERC20Burnable, ERC20Pausable {
   bytes32 public constant MINTER_ROLE = keccak256("MINTER_ROLE");
   bytes32 public constant PAUSER_ROLE = keccak256("PAUSER_ROLE");
   /**
    * @dev Grants `DEFAULT_ADMIN_ROLE`, `MINTER_ROLE` and `PAUSER_ROLE` to the
    * account that deploys the contract.
    *
    * See {ERC20-constructor}.
    */
   constructor(string memory name, string memory symbol) public ERC20(name, symbol) {

simply importing an interface in the head of your sol file, versus

Importing an interface would allow you to declare variables of an interface type to interact with contracts using the interface.

See the Solidity documentation for details on interfaces:

An example of importing an interface where you are not inheriting is using IERC20 to interact with an ERC20 contract:

github.com

OpenZeppelin/openzeppelin-contracts/blob/v3.2.0/contracts/token/ERC20/SafeERC20.sol#L22


* contract returns false). Tokens that return no value (and instead revert or
* throw on failure) are also supported, non-reverting calls are assumed to be
* successful.
* To use this library you can add a `using SafeERC20 for IERC20;` statement to your contract,
* which allows you to call the safe operations as `token.safeTransfer(...)`, etc.
*/
library SafeERC20 {
   using SafeMath for uint256;
   using Address for address;
   function safeTransfer(IERC20 token, address to, uint256 value) internal {
       _callOptionalReturn(token, abi.encodeWithSelector(token.transfer.selector, to, value));
   }
   function safeTransferFrom(IERC20 token, address from, address to, uint256 value) internal {
       _callOptionalReturn(token, abi.encodeWithSelector(token.transferFrom.selector, from, to, value));
   }
   /**
    * @dev Deprecated. This function has issues similar to the ones found in
    * {IERC20-approve}, and its usage is discouraged.

importing that interface AND ALSO using the ‘is’ keyword referring to that interface in your contract declaration

Importing and inheriting from an interface is just like inheriting from any other contract. Just like an abstract contract you would need to implement the functions defined in the interface.

An example of importing and inheriting from an interface is inheriting from IERC20:

github.com

OpenZeppelin/openzeppelin-contracts/blob/v3.2.0/contracts/token/ERC20/ERC20.sol#L34


*
* Additionally, an {Approval} event is emitted on calls to {transferFrom}.
* This allows applications to reconstruct the allowance for all accounts just
* by listening to said events. Other implementations of the EIP may not emit
* these events, as it isn't required by the specification.
*
* Finally, the non-standard {decreaseAllowance} and {increaseAllowance}
* functions have been added to mitigate the well-known issues around setting
* allowances. See {IERC20-approve}.
*/
contract ERC20 is Context, IERC20 {
   using SafeMath for uint256;
   using Address for address;
   mapping (address => uint256) private _balances;
   mapping (address => mapping (address => uint256)) private _allowances;
   uint256 private _totalSupply;
   string private _name;

abcoathup · November 30, 2020, 3:32am

Hi @CryptoEatsTheWorld,

Did you need any more information?

CryptoEatsTheWorld · November 30, 2020, 4:03am

No, thanks for the info.