You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: website/docs/design/design-for-composition.mdx
+5-6Lines changed: 5 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -39,13 +39,12 @@ We focus on building **small, independent, and easy-to-read facets**. Each facet
39
39
1. Every extension of a standard or facet should be implemented as a new facet.
40
40
2. A facet should only be extended with a new facet that composes with it.
41
41
3. Composition is done by facets sharing the same storage structs and containing complementary external functions.
42
-
4. Two facets do not compose if they both expose one or more of the same external function signatures (function name and parameter types).
42
+
4. Two facets do not compose if they both have one or more of the same external function signatures (function name and parameter types).
43
43
5. When reusing a struct from an existing facet, store it at the original diamond storage location and remove unused variables from the end of it. Variables must never be removed from the beginning or middle, as this would break storage compatibility.
44
44
6. Storage structs should be designed so that removable variables (unused by some facets) appear at the end of the struct.
45
-
7. Storage structs should also be designed for packed storage (smaller sized variables using the same storage slot).
46
-
8. If a variable cannot be removed from the end of a struct, it must remain to preserve compatibility.
47
-
9. A facet that adds new storage variables must define its own diamond storage struct.
48
-
10. Never add new variables to an existing struct.
45
+
7. If an unused variable cannot be removed from the end of a struct, it must remain to preserve compatibility.
46
+
8. A facet that adds new storage variables must define its own diamond storage struct.
47
+
9. Never add new variables to an existing struct.
49
48
50
49
:::info Important
51
50
Maintain the same order of variables in structs when reusing them across facets or libraries. Unused variables may only be removed from the end of a struct.
@@ -93,7 +92,7 @@ When reusing this struct in `ERC20PermitFacet`, the [Extending Facets](#extendin
93
92
94
93
`ERC20PermitFacet` only uses the variables `allowances` and `name` from this struct. However, `balanceOf`, `totalSupply`, and `decimals`**cannot** be removed, even though they are unused, because they appear before the `name` variable, which is used. Removing them would shift the storage slot used by the `name` variable which would make it refer to something else.
95
94
96
-
Only variables at the **end** of a struct may be safely removed. In this case, `symbol` is the only trailing variable that is unused by `ERC20PermitFacet`, so it is the only one removed.
95
+
Only unused variables at the **end** of a struct may be safely removed. In this case, `symbol` is the only trailing variable that is unused by `ERC20PermitFacet`, so it is the only one removed.
97
96
98
97
Here is the final struct storage code for `ERC20PermitFacet`:
0 commit comments