Open petrovska-petro opened 2 months ago
is this a common approach?
why not do the same as the errors, and have an
libraries/Events.sol
?im confused because the interface file this now creates does not actually provide a full interface to the vmodule (or factory), and is thus unusable for an external project trying to use those interface files for example
it is used in some of the codebases that i personally find the cleanest; file organisation wise. but it is a way of many
missed pushing before the methods before as it creates errs that i need to look further, but i agree that generally the should include the methods as well so they're reusable
then, we could use as well /// @inheritdoc X
natspec, which will copy the tags from the base contract, but somehow i still find valuable to have the comments in line w/ the function definition, even tho if we'd like to reduce even more the lines on the core contract, we could indeed use /// @inheritdoc X
why not do the same as the errors, and have an libraries/Events.sol?
it could be perfectly an abstract contract
, but i think the interface approach is best bang for your buck, since it can encapsulate the events + methods, and also if we'd like to go a mile further could move all natspec there and inherit
on the side of verification things, im not sure how it may affect tbh, smth to try out, but i imagine should not present a problem
closes #77