Open timPrachasri opened 4 years ago
If Type A (fungible), Type B (non-fungible) and Type C (fungible) all needed to be minted in your contract how would your code handle that situation?
@AC0DEM0NK3Y I don't get what situation did you mean since when minting there're two different functions for fungible and non-fungible (which are
function mintNonFungible(uint256 _type, address[] calldata _tos) external creatorOnly(_type)
function mintFungible(uint256 _id, address[] calldata _tos, uint256[] calldata _quantities) external creatorOnly(_id)
) and when identifying credit whether it is fungible or non-fungible there are a masking bit for that.
In your case (Type A (fungible), Type B (non-fungible) and Type C (fungible)), the id for A, B and C could be like the following (let say I store ID in the uint8 instead of the uint 256)
0000 0001
1010 0000
0000 0011
There is a common create function, that is where the code the OP mentioned was pulled from.
...and sure you could store it there yes, but now to get type you first have to test fungibility and then either use a mask or pull from uint8 (essentially a mask on the lower bits), and have limited yourself to 255 fungible types.
By storing the type in the same place for all you can use a common way to get the type from any id. But it's up to you, the id mechanism is up to the implementor this is just an example of how you could do it.
Why do ERC1155MixedFungibleMintable needs store the type of both fungible and non-fundgible in the upper 128 bits? For non-fungible it makes sense since the lower 128 bits are ID, but for fungible, why do we need to store the type in upper 128 bits as well
proposal
_type = (++nonce << 128);
in the conditionif (_isNF)
instead ?