-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update manager to support multiple implementation contracts #105
Conversation
src/auction/Auction.sol
Outdated
uint256 _reservePrice | ||
) external initializer { | ||
/// @param _data The encoded auction settings | ||
function initialize(address _token, address _founder, address _treasury, bytes calldata _data) external initializer { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
typically i prefer structs in this situation as noted in the diff notes due to sometimes lower code size and easier initialization on the front-end.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The _data parameter is a struct so clients will be using a struct to encode it still. the address params come from the manager contract. would a struct still be useful for the code size aspect?
@@ -82,9 +75,11 @@ contract Auction is IAuction, VersionedContract, UUPS, Ownable, ReentrancyGuard, | |||
// Store DAO's ERC-721 token | |||
token = Token(_token); | |||
|
|||
AuctionParams memory params = abi.decode(_data, (AuctionParams)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This also could be an inner struct – depends on how much you want to change things.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same comments as the other one mentioning structs @iainnash:
To create a struct with the addresses and data parameters we would need to copy the _data param (from calldata) and deployed addresses (from storage) to memory which might be more expensive than re-encodinga and passing the calldata I think
what are your thoughts on this?
src/governance/governor/Governor.sol
Outdated
uint256 _quorumThresholdBps | ||
) external initializer { | ||
/// @param _data The encoded governor parameters | ||
function initialize(address _treasury, address _token, bytes calldata _data) external initializer { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could pass in the generic struct here and _data as a part of that to prevent re-encoding and passing the calldata so many times.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To create a struct with the addresses and data parameters we would need to copy the _data param (from calldata) and deployed addresses (from storage) to memory which might be more expensive than re-encodinga and passing the calldata I think
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I want to take more time reviewing this but this is a first pass – would be helpful to not have all the linter changes here (But I think I have a tool to remove them) since this is a fairly large diff.
I'll think about a better way than the tagged array but that approach makes sense – more sense than nulling out a struct. another approach is a struct with an ID in it but that requires more iteration.
src/manager/Manager.sol
Outdated
governorImpl = _governorImpl; | ||
} | ||
// Public constants for implementation types. | ||
// Allows for adding new types later easily compared to a enum. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i believe at this point enums under the hood are uint8 – this just makes it more clear when you add items.
auction = address(new ERC1967Proxy{ salt: salt }(auctionImpl, "")); | ||
treasury = address(new ERC1967Proxy{ salt: salt }(treasuryImpl, "")); | ||
governor = address(new ERC1967Proxy{ salt: salt }(governorImpl, "")); | ||
metadata = address(new ERC1967Proxy{ salt: salt }(_implAddresses[IMPLEMENTATION_TYPE_METADATA], "")); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
salt isn't really needed but i don't think it hurts this – since our impl addresses now can change
forgot to fix the linter changes. updated now to match the original formatting |
@neokry havent dug deep into this yet but please run the storage generate script so |
uint256 implAddressesLength = _implAddresses.length; | ||
|
||
// Ensure implementation parameters are correct length | ||
if (implAddressesLength != IMPLEMENTATION_TYPE_COUNT || _implData.length != IMPLEMENTATION_TYPE_COUNT) revert INVALID_IMPLEMENTATION_PARAMS(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: {
and }
brackets.
Updates manager for upcoming V2 changes
Code Review