[book] transfer to object #106
Conversation
|
|
||
| Transfer to Object is not the only way to create a relationship between objects. There are more | ||
| flexible and feature-rich ways, such as the | ||
| [Dynamic Fields](./../programmability/dynamic-fields.md), which we explore in the |
There was a problem hiding this comment.
I do not know if this is the place for this comment, however as dynamic fields are referenced here, here it is:
Something that comes up a lot:
Should I use dynamic fields or TTO?
One major difference is that one does not need to have ownership of the owner-object in order to transfer an object to it.
Dynamic fields on the other hand can be seen as having more "control" on what is added "below" the owner object.
There was a problem hiding this comment.
Been thinking about it a lot and still don't have an answer. Technically, in the book, it is too early to mention dynamic fields (they come mid next chapter), yet dynamic fields are too far from transfer to object. Very good point, and very much worth discussing!
There was a problem hiding this comment.
In my mind it's not really an either/or of TTO vs dynamic fields. TTO is about transfer, dynamic fields are about ownership -- i.e. it's perfectly valid to have a protocol where you use TTO to transfer something to an object, and then when it is received, it is turned into a dynamic field on the object it was received on.
There was a problem hiding this comment.
@amnn I agree that they're not replacing each other (though, in some situations they do), but more of a guide which one is suited for which purpose.
| @@ -31,21 +31,27 @@ Transactions consist of: | |||
|
|
|||
| ## Inputs | |||
|
|
|||
| Transaction inputs are the arguments for the transaction and are split between 2 types: | |||
| Transaction inputs are the arguments for the transaction and are split between 3 types: | |||
There was a problem hiding this comment.
Technically they are split into four types:
- Pure arguments
- Owned or Immutable Object arguments
- Shared Object Arguments
- Receiving Object Arguments
There was a problem hiding this comment.
Great catch, will expand!
| Every object in Sui has its own `UID` which is represented by the | ||
| [address type](./../move-basics/address.md). This address can be used to query the object's data, |
There was a problem hiding this comment.
This may be a bit confusing to folks, because depending on context, an object's ID can be represented by a UID, ID, or address type. On this page the address representation is the most interesting/novel one, but in other circumstances (e.g. for dynamic fields) UID is more interesting, and in other circumstances (e.g. ID pointer) ID is more interesting.
Here seems like the wrong place to discuss this concept in detail, but it seems like something we should document somewhere.
| through their owner. The owner object needs to implement a custom function that will call the | ||
| `receive` function from the `transfer` module. |
There was a problem hiding this comment.
I'm so-so on the phrase "the owner object needs to implement..." because it sounds like interface implementation which is not a concept we have in Move. It also puts the focus on the custom receive function, and I'm not sure that's the focus for the object doing the receiving (the only thing that matters for the receiving object is that it exposes its &mut UID, but it's probably a good idea for that to be done in a limited way that means you can only use it for specific purposes). A custom receive function is more important for dealing with the object being transferred -- because if that object does not have store, it needs a custom function to call receive on it.
There was a problem hiding this comment.
Yeah, I also had this feeling, and I don't like it. The biggest blocker I faced on every attempt to write this page.
| /// For objects without `store` (though, they would require special handling), we | ||
| /// can implement the non-public version of the `receive` function. | ||
| public fun receive<T: key>(po: &mut PostOffice, to_receive: Receiving<T>): T { | ||
| transfer::receive(&mut po.id, to_receive) | ||
| } |
There was a problem hiding this comment.
Does this work? I would expect it to fail because of custom transfer rules (the non-public_ receive is being called on type T from a module that does not define T).
|
|
||
| Transfer to Object is not the only way to create a relationship between objects. There are more | ||
| flexible and feature-rich ways, such as the | ||
| [Dynamic Fields](./../programmability/dynamic-fields.md), which we explore in the |
There was a problem hiding this comment.
In my mind it's not really an either/or of TTO vs dynamic fields. TTO is about transfer, dynamic fields are about ownership -- i.e. it's perfectly valid to have a protocol where you use TTO to transfer something to an object, and then when it is received, it is turned into a dynamic field on the object it was received on.
Co-authored-by: Ashok Menon <[email protected]>
Adds missing Transfer to Object chapter