Is it frowned upon to store object address on-chain in struct?

[jillxuu]

Lets say i dont want callers to pass in object address but rather i want the address obtainable in move directly without relying on indexer or fn, if i have a struct to store the object address, is it frowned upon and why?

[gregnazario]

There's a tradeoff here:

A more generic solution, uses a provided object. This is useful for a shared marketplace contract, or something generic like taking any NFT for the marketplace.

This also takes full advantage of parallelism, and flexibility.

The use case specific system, you can either:

1. Store the object address in a struct or data structure, preferred but, if you're storing a lot of object addresses, you could be having more serialization from conflicts, which can be counteractive to the parallelism by using parallel objects.

2. Use a derivable named object. This can be useful as then you don't need to store anything, but you always need the address, and the seed used. AND you need to namespace from other contracts to make sure there aren't conflicts.

This doesn't particularly scale as well either, but can be useful for objects tied directly to a contract 1:1 or tied to a contract and a user 1:1.