Closed pipermerriam closed 1 year ago
@kclowes I just realized that this might end up being part of your async support work. We could probably model the functions
and events
APIs on the contract as extensions, which would naturally allow us to swap out the sync implementation for an async implementation of the Contract.events
and Contract.functions
APIs. In theory we could model the majority of the contract APIs using this extensions concept.
ethPM
will be deprecated in v7
, closing as wontfix.
What was wrong?
The
py-ethpm
library currently has to use a subclass of theContract
class to achieve some of the desired functionality (LinkableContract
).This approach isn't friendly towards any other code which also needs to extend the contract class in some way.
How can it be fixed?
Currently using the name "Contract Extensions".
A contract extension would be a class. Probably inheriting from a standard base class that does some internal plumbing that the user doesn't need to be concerned with.
The idea is to get things wired up such that
self
in the method above is the contract instance. We can do this with some which craft/sorcery/dark-magic.Then maybe use them like this:
Then from the contract instance:
In theory we can also expose an API for registering extensions that go on all contracts by default, or maybe event dynamically adding them at runtime after contract class/instance creation.
Taking this idea further could be doing thing likes:
before_deploy/after_deploy