chore: move the grc721 interface in p/grc/ #139
Conversation
| "strconv" | ||
|
|
||
| "gno.land/p/avl" | ||
| igrc721 "gno.land/p/grc/grc721" |
There was a problem hiding this comment.
Is it customary to name it "i"+name ?
I've been appending "m" instead, for "module". but I suppose not all packages are modules so...
There was a problem hiding this comment.
the i prefix is common for packages that only define interfaces
to be honest, I opened this PR early with this first split, but I'm considering more and more to not only push the interface but the interface + a minimal (official?) implementation, so anyone can import it and use the implementation, or import it to ensure having compatibility with the interface
no strong conviction on the naming yet, it's up to you :)
There was a problem hiding this comment.
the i prefix is common for packages that only define interfaces
to be honest, I opened this PR early with this first split, but I'm considering more and more to not only push the interface but the interface + a minimal (official?) implementation, so anyone can import it and use the implementation, or import it to ensure having compatibility with the interface
no strong conviction on the naming yet, it's up to you :)
There was a problem hiding this comment.
if it's stateless, it can still live in /p/grp, and it can be known to be "pure". so as long as the package doesn't have global variables that change value, all good. NOTE if a thing tries to modify a /p/xxx variable, upon realm finalization it panics (or it should). kinda wish gno/go would support the notion of "constant" variables for this reason.
|
perfect. |
Signed-off-by: Manfred Touron <[email protected]>
ecd83b5 to
01f236a
Compare
this PR does not bring real value to the NFT package itself, but intend to introduce the concept of having interfaces for common standards available from the
gno.land/p/grc/*packages.the concept becomes more interesting as soon as we have more than one, which is the case with #136 that introduces the GRC20
is it okay to go this way or better reducing the amount of imports and not a problem to mix implementation and interfaces for such standards?