fix(N-03): inconsistent error types #339
Conversation
Refers #336
✅ Deploy Preview for contracts-stylus ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
bidzyyys
changed the title
bidzyyys
force-pushed
the
336-audit-n-03-inconsistent-error-types
branch
from
be3c34b to
e24c024
Compare
| @@ -27,66 +27,90 @@ sol_storage! { | |||
| } | |||
| } | |||
|
|
|||
| impl BitMap { | |||
| /// Required interface of a [`BitMap`] compliant contract. | |||
| pub trait IBitMap { | |||
There was a problem hiding this comment.
Do you think we need that kind of abstraction for BitMap and Trace?
I considering them mostly as primitives and not separate contracts/extensions..
cc @ggonzalez94
There was a problem hiding this comment.
I would say that everything under contracts should have a trait.
There was a problem hiding this comment.
May be every function that is assumed to be publicly exposed should be in the trait? (public in solidity) In specified "contracts" there is no function that is assumed to be exposed publicly.
There was a problem hiding this comment.
Curious about @ggonzalez94 thoughts.
There was a problem hiding this comment.
I don't have a strong opinion here.... I don't think many people would use the trait and will only be interested in the implementation, but I guess for consistency it doesn't hurt to have them
There was a problem hiding this comment.
Since OL shared that they're going to stick to trait based approach.
And that in future we are expecting being able to declare #[public] macro more then once.
So this pattern can be done for every trait we have. That is why I'm considering to put just public methods into it.
Resolves #336