From a1fcf1c30ed864b761c118ab266526be4beb507c Mon Sep 17 00:00:00 2001 From: Josh Hannan Date: Mon, 11 Mar 2024 11:43:04 -0500 Subject: [PATCH] address gio and Jerome's comments --- application/20221219-nft-v2.md | 28 +++++++++++++++------------- 1 file changed, 15 insertions(+), 13 deletions(-) diff --git a/application/20221219-nft-v2.md b/application/20221219-nft-v2.md index 7412e795..605e99c0 100644 --- a/application/20221219-nft-v2.md +++ b/application/20221219-nft-v2.md @@ -1,9 +1,9 @@ --- status: Implemented flip: 56 -authors: Joshua Hannan (joshua.hannan@dapperlabs.com) -sponsor: Joshua Hannan (joshua.hannan@dapperlabs.com) -updated: 2024-02-20 +authors: Joshua Hannan (joshua.hannan@flowfoundation.org) +sponsor: Joshua Hannan (joshua.hannan@flowfoundation.org) +updated: 2024-03-11 --- # Non-Fungible Token Standard V2 @@ -100,8 +100,8 @@ access(all) contract interface ViewResolver { /// Function that resolves a metadata view for this token. /// Some contracts may have multiple resource types that support metadata views - /// so there there is an optional parameter for specify which resource type the caller - /// is looking for views for. + /// so there there is an optional parameter to specify which resource type the caller + /// is requesting views for. /// Some contract-level views may be type-agnostic. In that case, the contract /// should return the same views regardless of what type is passed in. /// @@ -171,7 +171,7 @@ it is a best practice to have getter functions return `nil` if something goes wr instead of panicking and reverting the transaction. ```cadence -pub fun borrowNFT(id: UInt64): &AnyResource{NFT}? +access(all) view fun borrowNFT(_ id: UInt64): &{NFT}? ``` ### Remove the requirement for the `ownedNFTs` field in `Collection` @@ -182,14 +182,14 @@ to store tokens in a unique way that is different what what could be specified. This proposal removes `ownedNFTs` and only requires a `getIDs()` method for the collection to indicate which IDs it contains. -### Move `createEmptyCollection()` to inside the Collection definition in addition to the contract +### Move `createEmptyCollection()` to inside the NFT and Collection definitions in addition to the contract It is useful to be able to create a new empty collection -directly from a `Collection` object instead of having to import +directly from an `NFT` or a `Collection` object instead of having to import the contract and call the method from the contract. ```cadence -pub resource interface Collection { +access(all) resource interface Collection { /// createEmptyCollection creates an empty Collection /// and returns it to the caller so that they can own NFTs @@ -206,8 +206,9 @@ pub resource interface Collection { Metadata Views for non-fungible tokens should be easily accessible from interfaces defined by the standard. -This propsal enforces that implementations implement the `ViewResolver` contract interface -and `NFT` implementations implement the `ViewResolver.Resolver` interface. +This proposal enforces that implementations implement the `ViewResolver` contract interface, +`NFT` implementations implement the `ViewResolver.Resolver` interface, +and `Collection` implementations implement the `ViewResolver.ResolverCollection` interface. ### Add support for getting information about Sub-NFTs @@ -325,7 +326,8 @@ within resources, avoiding public fields, and giving developers flexibility to w ### Tutorials and Examples -* Coming soon once the proposal reaches a more final state. +* Check out the Cadence 1.0 migration guide for instructions on how to update contracts to the new standards: + * https://cadence-lang.org/docs/cadence_migration_guide/ ### Compatibility @@ -348,7 +350,7 @@ to create scoped providers. This feature is out of the scope of this proposal, but should definitely be a standard that lives alongside the main fungible token standard. -We hope to shepard a proposal for these soon. +We hope to shepherd a proposal for these soon. ### Universal Collection