Skip to content

Commit cbe95aa

Browse files
Fibonacci747Amxx
andauthored
docs: remove legacy constructor visibility from upgradeable diff example (#6112)
Co-authored-by: Hadrien Croubois <hadrien.croubois@gmail.com>
1 parent 7d2fc5f commit cbe95aa

File tree

1 file changed

+2
-2
lines changed

1 file changed

+2
-2
lines changed

docs/modules/ROOT/pages/upgradeable.adoc

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -33,7 +33,7 @@ NOTE: Interfaces and libraries are not included in the Upgradeable package, but
3333
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.
3434

3535
```diff
36-
- constructor() ERC721("MyCollectible", "MCO") public {
36+
- constructor() ERC721("MyCollectible", "MCO") {
3737
+ function initialize() initializer public {
3838
+ __ERC721_init("MyCollectible", "MCO");
3939
}
@@ -74,4 +74,4 @@ You may notice that contracts use a struct with the `@custom:storage-location er
7474

7575
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].
7676

77-
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.
77+
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.

0 commit comments

Comments
 (0)