Objects

[Stebalien]

Iteratively working with large datastructures is somewhat painful. We currently have two options:

1. Return the root CID for the datastructure, enshrining the layout of the data (HAMT, AMT, etc.) in the contract's interface.
2. Provide some form of "cursor" over the data, requiring some back and forth and making it difficult to guarantee atomicity.

A third option would be "objects". I.e., the ability to pass a code CID and a state CID to the FVM and have the FVM instantiate an "object" that lives inside the current invocation container.

For example, let's say that contract A wants to list all NFTs in contract B.

1. Contract A calls IterateNFT() on contract B.
2. Contract B returns two CIDs: (code_cid, nft_root_cid). code_cid is the CID of a wasm module conforming to the wasm component model.
3. Contract A calls the syscall object::load(code_cid, nft_cid), getting back an object "handle".
4. Contract A can then call methods (component model methods) on this object directly.
5. Finally, contract A can call some object::close(handle) method to free the object's resources.

Important notes:

• Objects are completely isolated. They can read from their state-tree, but can't otherwise call out into the system.
• Objects can't "update" their state. Instead, the actor using the object would need to call some form of flush method on the object which would return the new root CID.
• Every object has a separate memory.
• There likely needs to be some way to pass objects to other objects, but I'm not sure how best to do so (likely requires wasm reference types).

Eventually, it would be nice to be able to model actors as "objects" owned by the system actor.

[vyzo]

I think View is a better name for the pattern you are describing, objects imply interior mutability capability.

[Stebalien]

Well, they do have mutability for as long as they're alive. They just don't have any way to persist their own state.