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
extend the import system by allowing "stateful modules" (that is, modules with top-level state variables). allow multiple instantiation of modules.
this is the second of two proposals exploring the stateful module design space; the other is #3722.
Motivation
the analysis here is substantially similar to the motivation presented in #3722. it is omitted here so that there is only one master copy of the analysis in case it undergoes edits or revision, but the discussion in #3722 should be considered requisite background for this proposal.
this proposal proposes an alternative design, which allows multiple instantiations of any given module, and solves the state sharing problem by allowing the programmer to share specific instances between modules. dependencies which are intended to be shared are marked as such at declaration time, and an instance needs to be provided before it can be compiled.
Specification
some examples, with a tentative syntax:
#### dep1.vy
counter: uint256####### dep2.vyimport dep1
# mark d as being something which will be initialized by some other module# note that dep2.vy is not a compilable until self.d is resolved!
d: dep1[noinit=True]
def __init__():
pass# self.d.__init__() is *not* allowed, because `noinit` is set to `True`@internaldef bar():
self.d.counter +=1####### contract.vyimport dep1
import dep2
d1: dep1
d2: dep2[d=dep1] # resolve d2.d to our d1def __init__():
self.d1.__init__()
self.d2.__init__()
@externaldef foo():
self.d1.counter +=1@externaldef foo1():
self.d1.update_counter()
@externaldef foo2():
t: uint256=self.d1.counter
self.d1.counter +=1self.d2.bar()
assertself.d1.counter == t +2
#### Foo.vyimport Lock
counter: uint256
lock: Lock[noinit=True]
@externaldef foo():
self.lock.acquire()
self.counter +=1raw_call(...)
self.lock.release()
####### Bar.vyimport Lock
import Foo
foo: Foo[lock=l]
x: uint256# this statement also controls the location of Lock in the storage layout -- it comes after `x`.
l: Lock
exports: Foo.foo
def __init__():
self.l.__init__(...) # omitting this would be an error!@externaldef bar():
self.l.acquire()
... # do stuff, maybe call an external contractself.l.release()
note an alternative design for this hypothetical project could be for Mint to instantiate Owned and BaseToken directly. then Contract.vy would use minter.acl. this would be a design decision left up to the library. for illustration, this is what that design would look like:
for future reference -- i started work on this in #3707. however, after side-by-side comparison, i am beginning to favor #3722 (with some modifications).
Simple Summary
extend the import system by allowing "stateful modules" (that is, modules with top-level state variables). allow multiple instantiation of modules.
this is the second of two proposals exploring the stateful module design space; the other is #3722.
Motivation
the analysis here is substantially similar to the motivation presented in #3722. it is omitted here so that there is only one master copy of the analysis in case it undergoes edits or revision, but the discussion in #3722 should be considered requisite background for this proposal.
this proposal proposes an alternative design, which allows multiple instantiations of any given module, and solves the state sharing problem by allowing the programmer to share specific instances between modules. dependencies which are intended to be shared are marked as such at declaration time, and an instance needs to be provided before it can be compiled.
Specification
some examples, with a tentative syntax:
an obligatory token example:
note an alternative design for this hypothetical project could be for
Mint
to instantiateOwned
andBaseToken
directly. thenContract.vy
would useminter.acl
. this would be a design decision left up to the library. for illustration, this is what that design would look like:Backwards Compatibility
does not change any existing language features, fully backwards compatible
Dependencies
References
Copyright
Copyright and related rights waived via CC0
The text was updated successfully, but these errors were encountered: