Why duplicating interfaces description files?

Khonsort · May 24, 2022, 9:33am

Duplicating the same interfaces declaration in different files (IERC...sol), one in @openzeppelin/contracts and one in @openzeppelin/contracts-upgradeable is not clear and complicate the understanding.

Moreover, IERC165Upgradable and others IERC...Upgradable are nonsense. I think the it is clearer to read contract ERC20Upgradeable is IERC20 { instead of contract ERC20Upgradeable is IERC20Upgradeable {

Why don't put all common declarations into a @openzeppelin/commons package ?

frangio · June 1, 2022, 10:22pm

Please see this issue:

github.com/OpenZeppelin/openzeppelin-contracts-upgradeable

Don't rename interfaces IWhatever -> IWhateverUpgradeable - It brings a lot of issues

opened 09:17PM - 09 Nov 21 UTC

gnarvaja

Also reported some time ago in https://forum.openzeppelin.com/t/why-contracts-up…gradeable-has-ierc721upgradeable-and-i-whatever-upgradeable/14793 **💻 Environment** openzeppelin-contracts == 4.3.2 openzeppelin-contracts-upgradeable == 4.3.2 **📝 Details** The package openzeppelin-contracts-upgradeable renames the interfaces when they are exactly the same as non-upgradeable (vanilla) versions. This isn't necessary and brings a lot of issues like this one **🔢 Code to reproduce bug** ```solidity interface IMyContract is IERC721 { ... } contract MyContract is IMyContract, ERC721Upgradeable { ... } ``` Then when I compile I get errors like these: ``` 11 | contract PolicyNFT is IERC721, | ^ (Relevant source part starts here and spans across multiple lines). Note: Definition in "ERC721Upgradeable": --> @openzeppelin/contracts-upgradeable/token/ERC721/ERC721Upgradeable.sol:184:5: | 184 | function safeTransferFrom( | ^ (Relevant source part starts here and spans across multiple lines). Note: Definition in "IERC721": --> @openzeppelin/contracts/token/ERC721/IERC721.sol:136:5: | 136 | function safeTransferFrom( | ^ (Relevant source part starts here and spans across multiple lines). TypeError: Derived contract must override function "safeTransferFrom". Two or more base classes define function with same name and parameter types. ``` I think XXXUpgradeable contracts shouldn't define new interfaces but instead implement the standard ones. Interfaces are the same between upgradeable and non-upgradeable contracts. If name clashes are an issue when importing files from `contracts` and `contracts-upgradeable`, those can be easily avoided using explicit imports ```solidity import {IERC20Metadata} from "@openzeppelin/contracts/token/ERC20/extensions/IERC20Metadata.sol"; import {ERC20Upgradeable} from "@openzeppelin/contracts-upgradeable/token/ERC20/ERC20Upgradeable.sol"; ```

Topic		Replies	Views
Why contracts-upgradeable has IERC721Upgradeable (and I<whatever>Upgradeable) Upgrades erc721 , upgrades	2	1940	September 23, 2022
Is IERC20Upgradeable removed from contracts-upgradeable? Contracts upgrades	1	1710	October 13, 2023
Can I use normal interface/library in place of upgradeable versions? Contracts proxies	2	627	June 27, 2023
Line 2 in every contract seems wrong. None of them give the correct file name Support	2	323	October 11, 2022
Discrepancy between docs, forums and wizard around upgradeable v5.x Support	2	28	July 18, 2024

Why duplicating interfaces description files?

Related topics