Import vs Import and inherit

CryptoEatsTheWorld · November 25, 2020, 7:44pm

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 26, 2020, 1:19am

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:
https://docs.soliditylang.org/en/v0.7.5/layout-of-source-files.html#importing-other-source-files

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:
https://docs.soliditylang.org/en/v0.7.5/contracts.html#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:
https://docs.soliditylang.org/en/v0.7.5/contracts.html#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.

Suveett · June 18, 2021, 9:15pm

Actually I do… I am honestly screwed up and Confused between Libraries, Interfaces and Imports

cameel · June 18, 2021, 11:42pm

@Suveett An interface is like a blueprint for a contract. It says what functions there are and what parameters they take but does not say what they actually do. If your contract inherits from an interface, the compiler will make sure that you do not forget to provide implementations for all its functions and that you do not change their signatures.

You can also use an interface to tell the compiler that a contract deployed at a particular address provides a particular set of functions. This way the compiler can know how to encode parameters for an external call without having access to the whole source code of the contract you’re calling.

One thing you did not mention but might be interested in are abstract contracts. You can think of them as a mix between a contract an an interface. They can have both unimplemented functions (like interfaces) and implemented ones (like contracts). The use case is usually different though. You’d typically create an abstract contract if you wanted to create an “incomplete” contract that cannot be deployed on its own and where the one inheriting from it has to fill the gaps. That’s usually better than creating a contract with empty function stubs because the compiler can check if all the right functions have been provided by the inheriting contract.

A library is just a special kind of contract. It has two uses:

Grouping internal utility functions. Any contract can access a library and all the internal library functions it calls become a part of its own bytecode. This is similar to free functions.
Splitting larger contracts into smaller pieces. Calling public and external library functions results in a DELEGATECALL - an external call that also gives the library access to contract’s storage (library functions can take storage parameters). I think this is used much less in practice due to the cost of DELEGATECALL and more complicated deployment (you need to deploy the library first and then tell the compiler to link in the address).

Imports are just… imports. If you have used any other language you’re probably familiar with imports/includes/requires/etc. They tell the compiler to make stuff defined in another file visible in the current file. Please read the docs linked above, they explain all of this in much more detail.

Suveett · June 19, 2021, 7:56am

Splitting larger contracts into smaller pieces. Calling public and external library functions results in aDELEGATECALL- an external call that also gives the library access to contract’s storage (library functions can takestorageparameters). I think this is used much less in practice due to the cost ofDELEGATECALL and more complicated deployment (you need to deploy the library first and then tell the compiler to link in the address).

Since we can just Import a Library(and hence access to its public/external functions and also the Library functions have power to compute and affect caller contract’s storage), OR we can just Import the Interface (with external unimplemented functions which need to be implemented but they don’t access storage of caller contract) then why do we in fact even need abstract contracts?, because all functionalities are already catered with Libraries and Interfaces, or is it not ??

If i Understand correctly, abstract contracts basically are to build small modularise contracts (Splitting larger contracts into smaller pieces), with extended functionalities and usage/access via “Internal functions” ?

So the difference is basically Internality and Externality, right ?? Am I understanding it correctly ??

& ALSO, if I understand it correctly, the abstract (aka base) contracts don’t get compiled and only the Most derived contract gets compiled on EVM using all the functions of abstract contracts as part of its own bytecode (and also because there are only INTERNAL calls between inherited contracts - derived contract => abstract contract ) WHEREAS Libraries need to be compiled because they access & change the state/ scope/ storage of Caller contract (through EXTERNAL Delegate Calls made by Caller)?, so the difference again is Internal vs External ??

Its a little bit too much to grasp, But I am slowly getting it…(if what i said above is correct) ??
Kindly Please revert and enlighten me

Thanks and Regards
Suveett Kalra

cameel · June 19, 2021, 7:54pm

then why do we in fact even need abstract contracts?, because all functionalities are already catered with Libraries and Interfaces, or is it not ??

Their main purpose is to let you extract common functionality from multiple contracts into one base contract. You can do this using a normal contract as well but if that base contract is incomplete and should not be deployed on its own or is missing some functions, marking it as abstract is just a way to tell that to the compiler. It's a completely different use case than libraries and interfaces. Libraries can't be used in the same way because you do not inherit from them. For example you cannot have virtual functions in a library and override them. And interfaces do not let you provide already implemented functions at all.

If i Understand correctly, abstract contracts basically are to build small modularise contracts (Splitting larger contracts into smaller pieces), with extended functionalities and usage/access via “Internal functions” ?

Yes. This is no different from normal contracts. The only difference is that abstract contracts do not have to be complete.

So the difference is basically Internality and Externality, right ?? Am I understanding it correctly ??

Yeah. Mostly. Interfaces are meant to define an external interface of a contract and you can use abstract contracts to define an internal interface.

Note however that you can have external methods in abstract contracts too. In fact they used to be used as ad-hoc external interfaces before a separate keyword for interfaces was introduced.
If you're interested in some language history, you can take a look at the discussions back from when these features were introduced:

& ALSO, if I understand it correctly, the abstract (aka base) contracts don’t get compiled and only the Most derived contract gets compiled on EVM using all the functions of abstract contracts as part of its own bytecode (and also because there are only INTERNAL calls between inherited contracts - derived contract => abstract contract ) WHEREAS Libraries need to be compiled because they access & change the state/ scope/ storage of Caller contract (through EXTERNAL Delegate Calls made by Caller)? , so the difference again is Internal vs External ??

The distinction does not really have anything to do with whether it's a library or an abstract contract. Both can have external and internal functions. In both cases internal functions are compiled into your own contract and external ones remain a part of another contract that is CALLED/DELEGATECALLED has to be deployed separately.

Suveett · June 19, 2021, 8:15pm

Thanks a ton. It really helped me a lot !!

Really appreciate your kind gesture

Topic		Replies	Views
Can't import ./Owned.sol on Remix Contracts	2	1969	March 9, 2020
Do I save fees through "import"? General	1	429	September 2, 2021
Best Practice Discussion: Should smart contracts inherit from their corresponding external interfaces? General	2	491	May 22, 2020
Use interface or a contract instance to interact with an existing contract General	4	384	May 11, 2021
ERC1155MetadataExtension imports IERC1155 Contracts erc1155	2	494	February 8, 2023

Import vs Import and inherit

Related Topics