Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix/erc721 #993

Merged
merged 2 commits into from
Jun 12, 2018
Merged

Fix/erc721 #993

merged 2 commits into from
Jun 12, 2018

Conversation

shrugs
Copy link
Contributor

@shrugs shrugs commented Jun 10, 2018

fixes #990

Based on my interpretation of This emits when the approved address for an NFT is changed reaffirmed., I made the approve() function remove the restriction on not allowing a reaffirmation of the address(0) approval.

The spec isn't detailed enough for this, it seems, so my interpretation might be wrong. Would appreciate feedback.

🚀 Description

  • 📘 I've reviewed the OpenZeppelin Contributor Guidelines
  • ✅ I've added tests where applicable to test my new functionality.
  • 📖 I've made sure that my contracts are well-documented.
  • 🎨 I've run the JS/Solidity linters and fixed any issues (npm run lint:all:fix).

Copy link
Contributor

@frangio frangio left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a bit confused by the sequence of commits 61ff1f7, 41bc037, and 878df54. The second reverts the first, and the third one implements the same thing again? 😅

Those lines are there because it was the semantics of Approval specified in the "Second Draft" of ERC721 that is listed in ethereum/EIPs#721. Look for the table in the description of approve. I actually loved that table because it was such a precise specification, but it was removed from the final version 😞 and now the semantics are not clear. I think always emitting Approval in approve is the safest thing.

_registerInterface(InterfaceId_ERC721Enumerable);
}

contract ERC721Enumerable {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Was removing the ERC721Basic parent intentional? If so, what is the rationale? (Same question for ERC721Metadata.)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah, it was not intentional thanks for catching that. made the mistake of removing both parents instead of just the 165 implementation one

@shrugs
Copy link
Contributor Author

shrugs commented Jun 12, 2018

your confusion over my commits parallels my own confusion while making them 😂

Copy link
Contributor

@frangio frangio left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, one last comment...



/**
* @title ERC721 Non-Fungible Token Standard basic implementation
* @dev see https://github.com/ethereum/EIPs/blob/master/EIPS/eip-721.md
*/
contract ERC721BasicToken is ERC721Basic {
contract ERC721BasicToken is ERC721Basic, SupportsInterfaceWithLookup {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Later on there is

contract ERC721Token is SupportsInterfaceWithLookup, ERC721BasicToken, ERC721 {

SupportsInterfaceWithLookup being last in one inheritance list and first in another might bring problems with linearization later on. I would stick to always first or always last. I'm not sure about any of this though. 😣 Damn C3.

@shrugs
Copy link
Contributor Author

shrugs commented Jun 12, 2018

Ok, I've clarified on ETH-NFT/Lobby that Approval should be emitted on a reaffirmation of 0->0, so this change is accurate.

@shrugs
Copy link
Contributor Author

shrugs commented Jun 12, 2018

via: ethereum/EIPs#1151

Copy link
Contributor

@frangio frangio left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Thanks @shrugs!

@frangio frangio merged commit e1dc141 into OpenZeppelin:master Jun 12, 2018
@shrugs shrugs deleted the fix/erc721 branch June 12, 2018 22:35
@fulldecent
Copy link
Contributor

Please consider to remove "WIP" from the PR title if a PR is merged.

@shrugs shrugs changed the title WIP: Fix/erc721 Fix/erc721 Aug 12, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Make ERC721 interfaces abstract again
3 participants