[move-std] Allowing deriving framework objects

[admin-aftermath]

Overview

With the recent addition of sui::derived_object, I have already ran into the desire to create a Coin, ObjectTable, etc using sui::derived_object::claim. As no framework modules expose constructors using sui::derived_object::claim this is impossible.

A common use case I've ran into a few times already is wanting to hold Coin<CoinType> as a DOF (or through ObjectBag or similar) of a parent object keyed by TypeName (i.e., std::type_name::with_defining_ids<CoinType>()). We could then easily query the parent object's balance of the Coin<CoinType> by deriving its ID offhcain as intended by sui::derived_object.

I think all framework objects would benefit from the ability to create them through sui::derived_object::claim, with Coin probably providing the most immediate impact.

[github-actions[bot]]

Thank you for opening this issue, a team member will review it shortly. Until then, please do not interact with any users that claim to be from Sui support and do not click on any links!

[zihehuang]

@damirka

[damirka]

Hey @admin-aftermath! I think I understand the behavior of the system you expect, however, there's a number of caveats in the "derive everything" approach. For example, for Coin type, how would it behave in join and merge scenarios? Also, you should be aware, that derived UID comes at a cost of a dynamic field attached to the parent (forever) and there's no reclaimability of a UID.

That said, I'm not sure if you're aware that derivation is actually a feature that always "existed": DFs are derived from the parent + key, and you can use this property to your advantage (ObjectBag / Coin<T> as a DF example). See Field type definition for reference and the very same derivation method used in derived_object.