Update extensibility pattern #303
Conversation
docs/Extensibility.md
Outdated
| - `A`: internal to a library, not meant to be used outside the module | ||
| - `B`: part of the public API of a library | ||
| - `C`: subset of B that is meant to be exported as-is by contracts |
There was a problem hiding this comment.
should we call them private, internal, and public? I don't want to coin any term that might conflict with the language down the road, or mix programming concepts and confuse people.
There was a problem hiding this comment.
my vote is to adopt private, internal, public. even if the safeguards aren't there yet this will still help developers coming from other languages wrap their heads around building new contracts and reading existing ones.
There was a problem hiding this comment.
I agree that those could definitely work^. I wonder if it'd be easier to use a more literal approach:
internal: internal to the lib...
public: part of the public API...
complete, finished, or something like that: ...meant to be exported as-is...
There was a problem hiding this comment.
external has a clash with @external - a @view func is also external
may I suggest final?
There was a problem hiding this comment.
but it's not really final since they can still be extended, most notably ERC20.transfer
There was a problem hiding this comment.
External makes sense to me. The clash with @external seems benign given that external functions should generally be wrapped in an @external function, no?
Resolves #295. I think the bits about constructors show that we need to differentiate between a contract constructor and a "library constructor". I think this is confusing enough to rollback and call them initializers.