Are away libraries the same concept/functionality as inheritance in solidity?
Like, if someone creates an NFT library, can anyone else import that and access the public methods?
In Sway, libraries are just modules containing functions and types. Any code you use from the library is included in the final code at compile time.
In Solidity, there are 4 ways to share functionality:
-
An internal Solidity library (a library with all internal functions) is just additional code that is embedded into the final smart contract at compile time (unused functions are removed). this is a popular approach.
-
An external Solidity library (library with at least one external function) is deployed as a separate contract and is accessed in the final smart contract through an external
delegatecall
(adelegatecall
preserves the current execution context but loads the library’s bytecode as an executable). The devex around this can be rough and is not very well documented, but it can be used in a pinch when a smart contract’s code size exceeds the EVM’s code size limit. -
There is a more “modern” way to declare functions and types at the file level in Solidity, this would be the most comparable to Sway libraries. Any used code is included in the final bytecode at compile time.
-
Finally there is inheritance, the messiest but most popular approach. Inheritance in Solidity allows the developer to define logic once in a parent contract, which can then be inherited in child contracts. The benefits are potentially gas efficiency if well-designed (all of the above require arbitrary code jumps or external calls) and storage is fully accessible in parent contracts whereas none of the above allow updating storage variables directly without assembly or a storage reference (currently only available with Solidity’s dynamically sized types, not primitive types). The disadvantages are inheritance hell, potential storage layout complexity, and in some cases, worse gas efficiency.
At the time of writing, Sway does not allow storage to be updated directly in libraries but this will change.
I’ll just add that there has been a lot of recent thought and design work going into how we want to allow library designers to provide APIs that interact with a contract’s storage.
You can follow along with the discussion at this issue, or jump to this comment to get a rough idea of the current plans.
is there any update on this? As far as I can see from here, abis can have traits as supertraits which is helpful, but requires re-implementation of the “inherited” abi trait. Any tips?
tagging @nedsalk @IGI-111 @anderson @calldelegation if y’all have any thoughts on ^. thanks!