Comments (8)
If this is included in comments, people will forget/will not know to write this
I think that as soon as it becomes a standard, it can become more common, and we can use linters. That's what go is doing. https://tip.golang.org/doc/comment
It's also easy to forget std.Payable()
.
In general, I believe that doc comments are more frequently read than the first lines of a function implementation for things that configure the metadata of a function. Personally, I usually examine the function signature and comments before considering reading the actual code.
This is not enforceable on a VM level - meaning people will still be able to make mistakes, wrongly calling functions.
I don't understand your point about mistakes.
Anyway, I don't understand the connection to the VM level if the goal is to generate better documentation for payable functions. It would make sense to have Go helpers if this also benefits other contracts. However, if this is solely for generating documentation when calling a function as an entry point, I don't see a need for the VM to be aware.
... they have a built-in function that reverts if its argument, the amount of tokens required ...
That's already doable by checking the std.OrigSend. We can eventually make a Assert helper.
I suggest you write some example contracts or pseudocode so we can review something and decide more easily. There was a very old issue about this concept, if I recall correctly, which was named "rules".
from gno.
To clarify, we need to add a field for each public function in a realm which will allow users to specify an
OrigSend
value to their call. Since we do not have a way to specify if a function can or cannot take Coins (unlike Ethereum'spayable
keyword - in Gno, if they're exported, they can receive coins), we should have this field for every function.OrigSend
should take in a a coin denom & amount, which will then later be packed in along with the transaction.Since the studio/connect repo is not public, what would be a good place for the team & contributors to leave feedback on the UI/UX of Connect?
Thanks @leohhhn @MalekLahbib @moul
May we add the feedback using the feedback realm?
Just to recap, the suggestion for Connect is to add an OrigSend
field to the interface (by default), allowing users to specify the coin denomination and amount directly when calling functions, since all exported functions in Gno are inherently payable. We could also use standardized comments to clarify the functions' purposes and how they handle coin transfers. Is this correct?
I thought of a suggestion by Alan related to a somewhat related issue (Clarifying Acceptable Argument Values for Function Execution) - to use godocs to create a specific comment structure that provides information on the arguments, so perhaps there is a way to enforce the comments for payable functions.
from gno.
No - every exported function is by default "payable". Gno is different from Solidity, and we want to keep as close as possible to Go syntax.
A consideration would be to add a std.Payable()
function which would be put at the beginning of the function you want to be payable. Same thing could be done for "view-only" functions, but not sure what others think. IMHO this would make it much clear what functions are meant for.
cc @moul
from gno.
I think we should start by playing with standardized comments that can be read both by humans and machines (gnoweb, wallets, SDKs).
Maybe something like this:
// Foo does foo things.
//
// @payable
// @...
func Foo() {}
from gno.
I see two issues with this:
- If this is included in comments, people will forget/will not know to write this
- This is not enforceable on a VM level - meaning people will still be able to make mistakes, wrongly calling functions.
I think adding a std.Payable()
and std.View()
or std.Readonly()
will help Gnomes enforce strict rules while not steering away from Go syntax. We can think about naming & in which package to put these functions in later. This also covers both of your points where it's readable by both humans and machines.
The above is Ethereum's way. I researched a bit on Solana & Aptos (Move lang), and they follow a different approach. To summarize, they have a built-in function that reverts if its argument, the amount of tokens required, is not available to be pulled from the callers balance - offloading the burden of sending coins from the user to the developer. Seems that Ethereum's way is much more approachable, considering how we manage our transaction context.
from gno.
To clarify, we need to add a field for each public function in a realm which will allow users to specify an OrigSend
value to their call. Since we do not have a way to specify if a function can or cannot take Coins (unlike Ethereum's payable
keyword - in Gno, if they're exported, they can receive coins), we should have this field for every function. OrigSend
should take in a a coin denom & amount, which will then later be packed in along with the transaction.
Since the studio/connect repo is not public, what would be a good place for the team & contributors to leave feedback on the UI/UX of Connect?
from gno.
@leohhhn @ilgooz @salmad3 is there a way to detect that a function is a "payable" function as in solidity?
from gno.
from gno.
Related Issues (20)
- A revert function to refund coins sent to a realm that doesn't take coins HOT 1
- importing "std" not working in gno.playground HOT 2
- Network peering discovery - Seed mode - Addrbook.json HOT 3
- Missing return value error in Poll tutorial HOT 2
- [gnokey] `Verify` and `Sign` functions now are not a pair HOT 2
- Proposal: Zero-Knowledge Proofs (ZKPs) for Login Process - Adena
- [Discussion] `std.ZeroAddress` HOT 5
- chore(docs): TODO removal
- amino.WithTypes accepts types being given the same name
- Public key format mismatch between `gnoland secrets init` and `gnoland genesis validator add` HOT 7
- [GnoVM]: Do not allow realms to store references to objects owned by other realms
- RFC(philosophy): Limiting depth of commands and subcommands in CLIs HOT 1
- RFC(philosophy): Merge some standalone repos into this monorepo
- [Discussion/Request] Add a way to catch emitted events in `gno test` HOT 1
- `Time.Now()` always return initial UNIX time HOT 2
- [gnokey] Make `gnokey query` more convenient HOT 3
- main README should disambiguate with gnosis project
- Oracle VRF HOT 2
- out of gas error is unclear `(VM call panic {WritePerByte})` HOT 2
- Incompatibility of `gnoland secrets init` with Read-Only mounted k8s Secrets
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from gno.