Nested namespace for library extensions

[andrew-fleming]

Nested namespace for library extensions

The current design of erc721_enumerable's library imports the ERC721 library and integrates the updated logic for:

• transfer_from
• safe_transfer_from
• _mint
• _burn

Contracts that utilize the enumerable extension are expected to import from both erc721 and erc721_enumerable libraries. I believe this is a bit messy and confusing since the enumerable functions share the same name. Prior to namespace, an alternative we considered was to rewrite every erc721 method in the erc721_enumerable library (which IMO is redundant but perhaps viable).

So I'm presenting a new approach which leverages namespace and nests the Enumerable extension within the ERC721 base namespace. Here's the gist for the library and preset contract.

---

Details

By removing the extra import and library module, it may be easier to use the enumerable logic.

# standard
`ERC721.transfer_from(from_, to, tokenId)`

# enumerable
ERC721.Enumerable.transfer_from(from_, to, tokenId)

If it seems reasonable, we could also include some sort of check with ERC165 that reverts if standard ERC721 contracts attempt to use ERC721.Enumerable.<method> and vice versa.

Things to consider

• the extensibility pattern rules will have to be amended regarding initializers
  • Must not call initializers on any function
• storage for erc721 enumerable's library will exist alongside erc721's storage
  • this could be changed when support for scoped storage variables is integrated
• the extended namespace can use functions with the same name as the base namespace, BUT it must include the base namespace scope i.e. _mint() within the ERC721.Enumerable namespace would call ERC721._mint()

This was done as an experiment, so I'd appreciate any feedback 🙏