feat: std re-organization #2425
Conversation
| // associated import path. | ||
| type Realm struct { | ||
| address Address | ||
| importPath string |
There was a problem hiding this comment.
What's the problem with PkgPath?
Edit: I think we should keep pkgPath over importPath. Because ultimately, the package path is an identifier which, yes, can be imported, but it's an identifier first, just as a std.Address is an identifier for an account. This one is the identifier for the realm and its assets, and the cool thing is that it's importable. It's like we would say that Go's package path can be imported, so let's not name them ImportPath. But we can also go mod download them, so let's not rename them goModDownloadPath either. I think we should be clear that the identifier is the unique identifier of a package, and then importPath is currently the same 1-1, but maybe in the future, we'll support import aliases for versioning or to support, for instance, r/morgan/foo and r/g1morganxxx/foo to be the same pkgPath but different importPath.
There was a problem hiding this comment.
I am for a different name that pkgpath, because it conflicts most of the time when explaining the topics, making it very confusing. possibly URL, URI, ID, just path, etc. in the end its a unique identifier for code, and it can be used to look up code or import code.
- realm path - better than realm package path
- pure package path - better than pure package package path.
| // Package runtime allows access to the GnoVM's runtime information. | ||
| package runtime | ||
|
|
||
| func NewReadOnlyBanker() chain.Banker { |
There was a problem hiding this comment.
I don't understand the benefit of having a distinct runtime package that ultimately implements helpers that will return chain types. Wouldn't it be simpler and less confusing to have a single package that defines the types and implements the helpers?
|
I like the refactoring idea and believe that most of the renames make sense. However:
|
| } | ||
|
|
||
| func (c Context) Run(f func()) { | ||
| } |
There was a problem hiding this comment.
func CurrentFileLine() string {
return ufmt.Sprintf("%s:%d", prevFrame.Filepath, prevFrame.LineNumber)
}
Or better GetFrameAt(x int).FileLine().
could be useful for things like uassert.
| import ( | ||
| "chain" | ||
| ) | ||
|
|
There was a problem hiding this comment.
XXX:
testing calls each test using a new Context{} (so that they're running always on a clean state)
same goes for subtests
a test may still call SetContext to just alter variables
There was a problem hiding this comment.
I think we should just run a new gnomachine, it’s not only about context,but about sharing any state (global variable too).
| func NewSendBanker() chain.Banker { | ||
| } | ||
|
|
||
| func NewIssueBanker() chain.Banker { |
There was a problem hiding this comment.
| func NewIssueBanker() chain.Banker { | |
| func NewIssuingBanker() chain.Banker { |
| func AssertOriginCall() { | ||
| } | ||
|
|
||
| func CallerRealm() chain.Realm { |
There was a problem hiding this comment.
I am of a hot take that we should completely remove the possibility of a realm being an EOA. It's a very confusing concept, especially when talking about realm package, package path, etc. Then, we could just have Caller, which can be a realm or an EOA/user.
| func CurrentRealm() chain.Realm { | ||
| } | ||
|
|
||
| func Deposits() chain.Coins { |
There was a problem hiding this comment.
We need to make a distinction between prevrealm deposits and origin deposits; rather, you only need to read the immediate previous realm deposit; I'm not sure of a usecase where origin deposit could be needed.
Related: #1887
| // Context contains execution context variables which are used primarily by the | ||
| // [runtime] package to give information about the current GnoVM execution. | ||
| type Context struct { | ||
| IsOrigin bool |
There was a problem hiding this comment.
what does this bool represent? that the caller is the origin caller?
|
|
||
| // NewCodeRealm creates a new realm, representing a code realm with a published | ||
| // import path, existing on-chain. | ||
| func NewCodeRealm(importPath string) Realm { |
This is a work-in-progress PR, but it contains some key ideas of the new design
References:
"std"package naming #1475std.TestXYZfunctions #1521stdpackage API more user-friendly #1576gno test#2338This will be worked into a complete state so that we can see the full extent of the transition to the new system, then it will be broken down into a few PRs for ease of reviewing, similar to what happened with #1695.
Objectives of this effort:
stdin favour ofchain,runtimeanddebug/testing.(This has not been discussed much yet, but the current "dual system" for standard libraries, is that p/ packages that serve as "testing aids" cannot use test-context functions due to the type checking. So I'm unifying the stdlibs, but disabling test-only features on-chain).
This is something I wanted to add for a while for consistency with Go.
Ie. make them work as in Go.
These are all individually up for discussion, but I think they fit nicely into a better std; so here it is.
Contributors' checklist...
BREAKING CHANGE: xxxmessage was included in the description