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
This is a big one. The idea is mainly to enable a multi-file workflow where Vyper currently pushes you to a single-file workflow.
Vyper's imports are currently limited to interfaces.
We want to support the following features:
import code (internal+external functions)
import structs
import events
We have a dumb implementation now: we have a c-style include! macro now that does what it sounds like. Notably, this is also how solidity's imports work when not specifying an object to import from the target file
Features to maybe implement❓🤨
Multiple imports of the same module
Does it make sense for a module to be imported twice? Kinda a contrived example but in theory could happen.
Let's say we have a contract that manages two sets of internal ERC20 logic/state. How should we handle this❓🤨
It wouldn't be too hard to write a macro that nests all the imported logic one level deeper into a hashmap where the lookup key represents "which" ERC20 module we're dealing with. Messy and ugly, but so is importing the same module twice
Import specific named items
Import a specific struct, function, event, etc.
Override an imported entity
So something like, import all the code from this file, but replace _____ with this thing
Modules
This is a big one. The idea is mainly to enable a multi-file workflow where Vyper currently pushes you to a single-file workflow.
Vyper's imports are currently limited to interfaces.
We want to support the following features:
We have a dumb implementation now: we have a c-style
include!
macro now that does what it sounds like. Notably, this is also how solidity's imports work when not specifying an object to import from the target fileFeatures to maybe implement❓🤨
Multiple imports of the same module
Does it make sense for a module to be imported twice? Kinda a contrived example but in theory could happen.
Let's say we have a contract that manages two sets of internal ERC20 logic/state. How should we handle this❓🤨
It wouldn't be too hard to write a macro that nests all the imported logic one level deeper into a hashmap where the lookup key represents "which" ERC20 module we're dealing with. Messy and ugly, but so is importing the same module twice
Import specific named items
Import a specific struct, function, event, etc.
Override an imported entity
So something like, import all the code from this file, but replace _____ with this thing
or something
The text was updated successfully, but these errors were encountered: