Open leohhhn opened 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.
Related with #1024
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 forstd
:DerivePkgAddr
>AddressFromPath
GetCallerAt
>CallerAt
GetBanker(BankerType)
>NewBanker(BankerType)
GetOrigSend
>OriginSend
CurrentRealm
,PreviousRealm
(instead ofPrevRealm
) should return the current Realm object and the previous caller (be it another realm or an EOA). This also needs to be discussed as these functions can be called in packages, and that isn't really consistent or logical naming.CurrentRealmPath
> just useCurrentRealm.Path
GetChainID
>ChainID
GetHeight
>BlockHeight
GetOrigCaller
>OriginCaller
GetOrigPkgAddr
- the naming of this function is unintuitive - we are using the terminology "Origin Caller" to get the EOA that signed the initial transaction, but we expect the Origin Package to be the current realm/package that is having its code executed. IMHO, this should be completely removed in favor of CurrentRealm.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 renamingaddpkg
commands ingnokey
& related tools todeploy/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.