The Mental Model of Programs

[richardpringle]

Right now, conceptually, an external program is actually just a namespace on the state with a bunch of functions.

If we want to make it look more like an "object", I think we're going to need to change a few things.

#[state_keys]
enum StateKeys { ... }

#[program(state_keys = StateKeys)] // macro does `impl StateAccess<StateKeys> for Token {}`  (not exactly, but more or less)
struct Token;

impl Token {
    pub fn init(&mut self, ...) {
        let state = self.state(); // `StateAccess` method
        let ctx = self.context(); // the context here would probably be immutable (like a view) 
    }
}

That leads to a more interesting import

impl SwapExchange {
    pub fn swap(&mut self, token_a_amount: u64, token_b_amount: u64) { 
        let a_output_amount = // do some magic
        
        // do stuff
 
        let token_a_id = self.state().get(StateKeys::TokenAId);
        let token_a = Token::from(token_a_id);        

        token_a.transfer(a_output_amount, self.context().id(), token_a_id)
    }
}

HOWEVER

This only makes sense for specific implementations... We would want a FungibleToken trait so that you can drop any token there.

side-note:
There's a whole other discussion to be had here about how the trait is implemented. Would it be possible to pass our state to another logic library?... there could be some nice optimizations if we do that both for on-chain footprint and AOC of commonly used libraries)

And all of a sudden, this whole thing is looking A LOT like Solidity. The one thing that I actually prefer is state access is still explicit instead of implicit with properties of the struct.

The alternative isn't amazing either, to be honest

We keep the function invocation paradigm, and we have to do something that looks more like this:

use token::transfer;
// ...
    let transfer_result = transfer(id, amount, from, to); 

The reason we have to pass the id in like that is because there's nothing that actually connects all the public functions. We can't make each function a method on a trait because each time the public macro is invoked, it's not aware of the other code.

We could also do something like build another context

    let token_context = ctx.ext_context_for(token_id);
    transfer(token_context, amount, from, to);

I think the way I would do the above, is change the first argument to #[public] functions to a &mut Context and have Context::ext_context_for return &Context. That method can also force a cache-flush (but that's not the important part here).

Instead, we could also make the first argument of every public function an impl Context or similar such that using an injected context vs one created by a user both kind of fit the calling convention (even though there's some macro magic behind the scenes).

In any case, we don't need to make any decisions just yet. This is just a stream of consciousness that I wanted to capture somewhere and leave open for comment.

[patrick-ogrady]

Right now, conceptually, an external program is actually just a namespace on the state with a bunch of functions.

This is a great summary of our current design. It works super well for "autonomous programs" but means that any interacting programs need to "negotiate" the namespace boundary.

For tokens deposits, we've discussed creating "proxy accounts" that another program can access to claim balance from another program (i.e. deposit(amt, address)). If any deposit is left unused, the program could simply revert.

[iFrostizz]

Tiny remark, if we use modules instead of a struct (which is not really needed because it should have no field), we can use our programs with bindings, even for testing more idiomatically. See #1065