Comments (8)
Yup, your understanding is correct and makes sense to me.
I believe that if we make another SNIP that touches the same parts of the interface that a previous SNIP has changed, we'll either say that it requires the previous SNIP, or the fields it adds will be optional so if a contract isn't returning a field you need, you'll just get a None somewhere and will have to deal with it.
from secret-toolkit.
A quick question to this: Would the new modules only include the additions and changes to snip20 or would you rather have it to mirror everything?
Concrete example: If I call Transfer on a snip21 do I import it from ::snip20 or ::snip21 ?
from secret-toolkit.
Good question, that's the discussion that i'd like to have here.
We could perhaps provide an alternative implementations to some things under snip21
, e.g. a Transfer
implementation with the memo
, and then pub use
(reexport) the interfaces that didn't change. That way we don't have to implement things twice, but users can still access everything they need from one module.
The question though then becomes: does snip22
include snip21
? Since snip22
is completely orthogonal to snip20
and snip21
we could have it export only the new messages that it defines, but then there's a certain asymmetry between them. Is that ok? I think it's a fine decision to make for now.
(I'm gonna explain that in the relevant PRs in a few minutes but) We're going to shelve snip23
(allowance improvements) for now, but if we were to include it, how would we represent it in the toolkit? just like snip21
, it adds new messages AND extends existing ones. What should/would the snip23
module export?
from secret-toolkit.
I would personally prefer asymmetry in the packages. So the functionally resides in the package it is defined in and I compose it in my contracts. That will mean that I potentially have multiple crates to import but it also makes it very clear which functionality I am using when writing the contract.
For something like the snip23
it would make sense to reexport functions and then I as a developer can choose which one I want to import and use. Here I am not sure how well intellisense works for Rust but in C# it would give me the tooltip like 'You are missing function Transfer, do you want to import it from ::snip20, ::snip22 or snip:33
from secret-toolkit.
Yeah, at least in CLion if you use a symbol you didn't import, it offers several options, and pastes in the appropriate import line next to your other imports.
from secret-toolkit.
So just to make sure, in your opinion should snip21
export all the symbols from snip20
, or not?
from secret-toolkit.
I think it should not export unchanged symbols. This is based on my following understanding (and please correct me if I am wrong here): Snip2X implementations are composable functionality- So my token could be based on snip20 and implement snip22 and 21 as well. Or potentially only 22 and so forth.
If we re-export snip20 from snip22 I would expect to have similar structure for snip21 and a similar one for snip21+ snip22 so the number of permutations rises exponentially with future improvements.
Instead I would suggest that I have a base functionality in snip20 and I can choose to pick a modern replacement from another crate to use it instead. This does still not solve the problem how I would solve the problem if two snips improve on the same symbol, but for the current moment this seems to be the clearest way for me.
from secret-toolkit.
We ended up including all new SNIP-2x functionality in the snip20
module. As far as I'm concerned we can still reshuffle this as discussed in this thread and release a new version, but for now let's experiment with it and see what feedback we get.
from secret-toolkit.
Related Issues (12)
- Standard answers for common use cases
- SNIP-20 Register & Receive implementations HOT 1
- Standard admin interface implementation HOT 3
- Token integer type for safe math operations
- Standard viewing keys implementation HOT 1
- Support failed queries HOT 11
- Support for permits outside contracts HOT 2
- secp256k1 unit tests dont compile HOT 2
- Panic! when trying to revoke_permit(Branch cw-v1.0) HOT 2
- implement SNIP-24 queries functionality
- Use a pure rust secp256k1 implementation HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from secret-toolkit.