Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

State Schemas #29

Open
fergalwalsh opened this issue Dec 5, 2022 · 1 comment
Open

State Schemas #29

fergalwalsh opened this issue Dec 5, 2022 · 1 comment

Comments

@fergalwalsh
Copy link
Collaborator

Tealish could allow the developer to define a schema for Global & Local states. The schema would serve two purposes:

  • indicate the number of int & byte slices used by the app
  • naming & typing of state keys

The schema should also allow for dynamically named state fields.

The syntax below is just an idea at this stage

Static state keys could be accessed using a field lookup syntax just like structs & Boxes. e.g

assert(Txn.Sender == GlobalState.manager_address)

Local state keys could use something like this:

assert(Txn.Sender == LocalState[account].manager_address)

When dynamic keys are required the existing opcodes (app_global_get & app_local_get ) should be used unless a good argument can be made for having additional syntactic sugar for these.

The schemas would be queryable from the Tealish language model of the program to allow other tools to export/consume them.

Needs more fleshing out before implementation.

@barnjamin, do correct me if I have mangled your idea :) And please add any further detail you have in mind at this stage.

@barnjamin
Copy link
Contributor

looks pretty good to me! the syntactic sugar for the dynamic (or reserved) state vals is also a potential footgun if you allow something like:
LocalState[account].my_dynamics[thing] and no default namespace is applied to the keys

How would you allow declaration of the state vals? is there some context in which they're declared/identified by the parser/compiler?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants