Utility package to specify general function conditions about gno HOT 3 OPEN

This is an excellent idea!

We should start writing helpers in gno.land/p/something (not rules, can be too many different things) and consider making a top-level package only after encountering limitations with this method.

BTW, I prefer the procedural over declarative.

My 2cts:

• declarative makes more ambiguous stack traces.
• for listing a set of conditions and makes building a code parser easier -> I disagree. It's straightforward to parse in both cases.
• less indirections.

If you're concerned about readability, we can use idiomatic go like this:

func Foo() {
    {
        rules.AssertPayable()
        rules.AssertReadOnly()
        rules.AssertPayableWith("...")
        // ...
    }

    // ...
}

But I think keeping them at the top of functions with an empty line just after will be more than enough.

The good news is that we can manage to support both at the same time, but I'll prefer the procedural method for the official packages' implementation.

from gno.

Sounds good to have a package in p for this. I was wondering if it would possible to implement ReadOnly through this method since it would be something quite useful.
For procedural vs declarative, I guess it's personal preference, using brackets is actually already visual.

from gno.

I think a more go-ish approach would be to use comments to give more context to the clients, generate documentation, and so on.

It's the current way Go extends a source code for things that are for tools and humans.

Having a library for rules still makes sense for real assertions, i.e., I would not prevent people from making TXs for read-only stuff, a TX is more decentralized and uses the consensus + it will be IBC friendly.
So, for the example of read-only, I would add comments to suggest people call it using RPC instead of TX but not prevent it.

Also, mixing actual code and magic is more obscure than having explicit code for code and explicit comments for everything else non-code.

I suggest that anyone starts a rules package that will make sense. And consider parsing comments instead of code for everything related to annotations/suggestions.

from gno.