Why does ERC1155MixedFungibleMintable needs store the type of both fungible and non fundgibl about erc-1155 HOT 3 OPEN

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?

from erc-1155.

@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)

• A: 0000 0001
• B: 1010 0000
• C: 0000 0011

from erc-1155.

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.

from erc-1155.