Context:
I would like to write an standard ("future ERC") with a set of rules to be respected by contracts implementing the standard. Such rules can include for example:
- "public function A must emit event XYZ when some internal state is modified".
- "public function B must throw if assertion over given execution state do not match".
- ...
Problem: Are there any "good solidity patterns" to define such standard so that implementations can just reuse the Solidity code?
For example, a common programming pattern will be to define "light-weight interfaces" that implementations are forced to override, each interface defining cross-cutting concerns. This is a non-issue.
My doubt arise when trying to define more "dynamic execution conditions", for example force set of events to always be present or force a given event to be raised.
In standard OOP programming languages like Java I can force implementations to always inherit from a given base class and just children implement "hooks" (or life-cicle functions in code), so that the standard will be restricted to a given base-class implementation.
Will such approach (forcing to inherit from a well defined base class) be suitable for general ERCs specs?
Can modifiers in functions be present in the formal spec?
Are you aware of some other "magical" programming pattern that could help to formalize in solidity code the expected behavior?
