-
Notifications
You must be signed in to change notification settings - Fork 1
These examples would be clearer in a namespace #85
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: rinderknecht@new_jsligo
Are you sure you want to change the base?
These examples would be clearer in a namespace #85
Conversation
type storage_type = int | ||
type return_type = operation list * storage_type |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are we doing the type x_type
thing?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I usually do that to distinguish types from values. Otherwise statements like storage: storage = ...
can get confusing.
[], store + value | ||
|
||
[@entry] | ||
let increment (delta : int) (store : storage) : ret = [], store + delta |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the previous names seems better overall, increment, decrement and delta vs add, sub and value.
@@ -1,15 +1,18 @@ | |||
type storage = int | |||
module Counter = struct |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, why the module wrapper?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For consistency with the JsLIGO example? I suppose it's not necessary here except that devs probably put most contracts in a module. If you think it's distracting I'll take it out.
I think these should be in a namespace/struct for clarity. In the case of jsligo it's necessary to know whether the
@entry
annotation should be in a comment or not.