From e194f5f2d22c6a790bbcfbed5568705661ab2de2 Mon Sep 17 00:00:00 2001 From: Fibonacci747 Date: Fri, 14 Nov 2025 10:06:36 +0100 Subject: [PATCH] docs: remove legacy constructor visibility from upgradeable diff example --- docs/modules/ROOT/pages/upgradeable.adoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/modules/ROOT/pages/upgradeable.adoc b/docs/modules/ROOT/pages/upgradeable.adoc index 6d252d8fac7..4ab101048b4 100644 --- a/docs/modules/ROOT/pages/upgradeable.adoc +++ b/docs/modules/ROOT/pages/upgradeable.adoc @@ -33,7 +33,7 @@ NOTE: Interfaces and libraries are not included in the Upgradeable package, but Constructors are replaced by internal initializer functions following the naming convention `+__{ContractName}_init+`. Since these are internal, you must always define your own public initializer function and call the parent initializer of the contract you extend. ```diff -- constructor() ERC721("MyCollectible", "MCO") public { +- constructor() ERC721("MyCollectible", "MCO") { + function initialize() initializer public { + __ERC721_init("MyCollectible", "MCO"); } @@ -74,4 +74,4 @@ You may notice that contracts use a struct with the `@custom:storage-location er Without namespaced storage, it isn't safe to simply add a state variable because it "shifts down" all of the state variables below in the inheritance chain. This makes the storage layouts incompatible, as explained in xref:upgrades-plugins::writing-upgradeable.adoc#modifying-your-contracts[Writing Upgradeable Contracts]. -The namespaced storage pattern used in the Upgradeable package allows us to freely add new state variables in the future without compromising the storage compatibility with existing deployments. It also allows changing the inheritance order with no impact on the resulting storage layout, as long as all inherited contracts use namespaced storage. \ No newline at end of file +The namespaced storage pattern used in the Upgradeable package allows us to freely add new state variables in the future without compromising the storage compatibility with existing deployments. It also allows changing the inheritance order with no impact on the resulting storage layout, as long as all inherited contracts use namespaced storage.