-
Notifications
You must be signed in to change notification settings - Fork 11.9k
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
Expose ERC721 getters internally #1993
Comments
@nventuro
Proposed change:
Is this the correct understanding? Why this confusion? |
That's because they are currently already exposed externally, but they should also be available internaly. |
@balajipachai correct! I meant |
@nventuro and @frangio
Can't we just use this.externalFuncName wherever required within the contract instead of making them public? |
The |
@nventuro Ok cool, out of curiosity how do you guys come to know that there will be CALL, DELEGATECALL etc OPCODE is involved? Could you please suggest some links wherein I could get information about this? And yes will start changing the functions to public from external. Thanks. |
ERC721 is a library, mostly inherited by other contract. The modifier external view tells the EVM that the function reads from the Blockchain and it getters available outside the contract. "The idea is reducing gas cost!!!!!! and making the getters available outside the contract (inheritable)" not otherwise https://ethereum.stackexchange.com/questions/19380/external-vs-public-best-practices/55426#55426 |
|
Spawned from #1970
Currently,
name
,symbol
,tokenURI
and (soon to be added)baseURI
areexternal
. The reason for this is not open up the API unnecessarily, but in this case little harm can come from providing these methods, and havingpublic
getters would allow users (and ourselves) to implement interesting mechanisms, such as auto-generated tokenURIs.We should change all of these getters to
public
.The text was updated successfully, but these errors were encountered: