added FungibleTokens contract (plural!) #60
Conversation
There was a problem hiding this comment.
Thanks for proposing this! Great suggestions. Like I said in the issue, we have a rough draft of a more fundamental change to the standard that we are going to propose soon, so this might not be needed, but if the community decides that we don't want to have to go through managing all those breaking changes, then this might be a great start for a alternate solution.
| } | ||
| } | ||
|
|
||
| pub resource Collection: FungibleTokens.CollectionPublic, FungibleTokens.CollectionPrivate { |
There was a problem hiding this comment.
I love the idea of having collections for multiple fungible tokens. I think we'll definitely want to integrate something like this in the standard
There was a problem hiding this comment.
I basically tried to create something that follows existing patterns from FT/NFT interfaces as there has been very little talk of updating the existing standard and the longer they are left in their current form the greater the friction breaking changes will introduce.
|
|
||
| init() { | ||
| self.totalSupplyByID = {0: 1000.0} | ||
| self.CollectionStoragePath = /storage/ExampleTokens |
There was a problem hiding this comment.
Probably needs a more specific name
There was a problem hiding this comment.
Are you referring to CollectionStoragePath or the example storage path?
There was a problem hiding this comment.
The path value itself. Maybe something like /storage/flowFungibleTokenExampleCollection
|
|
||
| // Requirement that all conforming TokenVault smart contracts have | ||
| // to define a resource called TokenVault that conforms to Provider, Receiver, Balance | ||
| pub resource TokenVault: Provider, Receiver, Balance { |
There was a problem hiding this comment.
I think that it would probably be good to also have this implement the FungibleToken.Provider, FungibleToken.Receiver, and FungibleToken.Balance interfaces
There was a problem hiding this comment.
How would that work? (they return different Types and we can't use the existing Vault as it has no ID)
There was a problem hiding this comment.
They have different types, but you can always cast those to the correct type if needed. It would make this more interoperable
There was a problem hiding this comment.
Sorry @joshuahannan I still don't see how the interfaces can be compatible/conformant, do you mind showing me how that might work?
There was a problem hiding this comment.
My bad. I was assuming that these still were compatible with FungibleToken, but of course they aren't. I don't think this will work then because they would still need to be compatible. We're working on the new proposal so we'll be sharing it soon.
There was a problem hiding this comment.
My idea is to introduce this as a new standard not to replace the existing one, so anyone who wants to support these tokens could integrate the complementary 'plural' standard.
Main drawback with breaking change to FT I see is how long will it take for exchanges to update? They already struggle with the smallest change....
Added FungibleTokens contract
#59