Check out the Issue Explorer
Looking to fund some work? You can submit a new Funded Issue here.
### What is wrong?
Currently, the `Computation` object houses *lots* of information and sub-APIs for things like maniputlating the stack, consuming gas, etc. This creates a lot of public API surface area since we are effectively support *two* public APIs for anything needed from a sub-property of the `Computation` object.
- `Computation.memory` is the API for getting at the `Memory`
- `Computation.memory.read` is the API for reading from memory.
### How can it be fixed
I propose moving **all** sub-APIs to private properties and only exposing them through a single public API on the `Computation` object itself.
- `Computation.memory -> Computation._memory`
- `Computation.memory.read() -> Computation.memory_read()`
In the process we should organize the body of the `Computation` object by subject/sub-API meaning that we co-locate all of the *memory* APIs together, and so on for each category.
#### Maybe use abbreviated suffixes
Some of these accessors can be long:
For APIs that are unambiguous like this one we can just use:
However, some APIs will need to be prefixed such as `Computation.stack.pop()`. In cases like this we should use a prefixed method name:
#### Common base class
The `BaseComputation` class should be converted to have only STUB implementations of these methods with `NotImplementedError` exceptions being raised in the methods.
Then, a `Computation` class can be created at `evm.computation.Computation` which contains all of the current implementations of these methods.
This should also include a page in the `docs/` that lists all of these APIs and has a basic human readable description of what they do.