gnolang / gno

Gno: An interpreted, stack-based Go virtual machine to build succinct and composable apps + Gno.land: a blockchain for timeless code and fair open-source.
https://gno.land/
Other
880 stars 364 forks source link

Making the `std` package API more user-friendly #1576

Open leohhhn opened 8 months ago

leohhhn commented 8 months ago

Description

This issue is meant to discuss potential changes to the std package API & naming. There are multiple issues/discussions on how this should happen, ie https://github.com/gnolang/gno/issues/1475 & https://github.com/gnolang/gno/issues/1521. Extracting parts of @thehowl's proposition on renaming things out of https://github.com/gnolang/gno/issues/1475 for std:

A broader discussion is related to if we are going to keep IsOriginCall & AssertOriginCall. These functions basically limit the caller of the transaction to be an EOA - and this blocks a lot of possible functionality, like account abstraction, smart contract wallets, & calling realms code through your code. I am personally in favor of simply removing these from the codebase.

While we are on this note, consider renaming PkgPath > Path - it is confusing that we can have packages that have package paths, but we can also have realms that have package paths ("you need to get the realm package path"). This would include making the changes in all tools as well. With this, we can also discuss renaming addpkg commands in gnokey & related tools to deploy/upload/publish.

I am not discussing the std package split as per @thehowl's comment, since AFAIK it is blocked by some other issues.

Another thing to keep in mind with these discussions is to have the std.TestXXX functions match the above, as discussed in https://github.com/gnolang/gno/issues/1521.

Please, read the other issues and put down your thoughts - this is a relatively urgent issue, since if we want to do any big renaming efforts, it would be better before we have a large dev base with a lot of apps, because the renaming would be a breaking change.

moul commented 8 months ago

DerivePkgAddr > AddressFromPath

"Address" and "Path" have ambiguous meanings.

Perhaps we could consider implementing something like this in Go:

type Package struct {
    Path string
}

func (p Package) Addr() std.Address {}

CurrentRealm, PreviousRealm (instead of PrevRealm)...

I agree to add CurrentRealm, but I prefer using PrevRealm instead of PreviousRealm. I'm open to discussing this further.


Everything else appears fine at the moment.

moul commented 8 months ago

Related with #1024