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

Update CryptoPizza to inherit from OpenZeppelin ERC721 implementation #163

Open
abcoathup opened this issue Dec 6, 2019 · 4 comments
Open
Assignees
Labels
feature-request New feature or request

Comments

@abcoathup
Copy link
Contributor

Summary

Update CryptoPizza to inherit from OpenZeppelin ERC721 implementation rather than create a separate implementation.

Motivation

https://studio.ethereum.org/ will likely be the entry point for many new developers to the space.

Whilst an example of how to implement ERC721 is useful, it may be more beneficial to show how to appropriately inherit from OpenZeppelin Contracts implementation.

Describe alternatives you've considered

The alternative is to provide some guidance in the README that developers could inherit from OpenZeppelin Contracts ERC721 implementation instead.

Additional context

Disclosure: I am the Community Manager at OpenZeppelin

@ChrisChinchilla
Copy link
Contributor

Is this not what it does already?

@abcoathup
Copy link
Contributor Author

Is this not what it does already?

@ChrisChinchilla currently CryptoPizza inherits from the interface IERC721 and creates its own implementation. Instead CryptoPizza could inherit from the OpenZeppelin implementation of ERC721, then the code could be simpler and just focus on the Pizza DNA and uniqueness (as an aside, a mapping to check if a Pizza name exists would be better than a for loop which doesn't scale).
https://docs.openzeppelin.com/contracts/2.x/api/token/erc721

@ChrisChinchilla
Copy link
Contributor

OK, then this is going to be more of a task for the devs here, or a task I can tackle, but not right now, so it may not happen immediately.

@javier-tarazaga
Copy link
Contributor

@abcoathup great addition and great point. If you guys already do have an implementation there is no need at all to implement it in the template itself.

@javier-tarazaga javier-tarazaga added the feature-request New feature or request label Jan 23, 2020
@ChrisChinchilla ChrisChinchilla self-assigned this Feb 7, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-request New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants