-
Notifications
You must be signed in to change notification settings - Fork 113
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
NEP: NeoContract ABI #12
Conversation
Really nice 👌 |
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.
Some minor spelling/grammar errors
NeoContractABI.mediawiki
Outdated
|
||
==Abstract== | ||
|
||
An application binary interface (ABI) is the interface between two program modules, one of which is often a library and/or operating system and the other one is usually an application created by a regular programmer. |
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.
Application Binary Interface
NeoContractABI.mediawiki
Outdated
|
||
<code>entrypoint</code> indicates that which is the entry point of the contract in <code>functions</code>. | ||
|
||
<code>functions</code> is an array of Function object which describes the details of each function in the contract. |
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.
Function objects which describe
NeoContractABI.mediawiki
Outdated
|
||
<code>functions</code> is an array of Function object which describes the details of each function in the contract. | ||
|
||
<code>events</code> is an array of Event object which describes the details of each event in the contract. |
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.
Event objects which describe
NeoContractABI.mediawiki
Outdated
<pre> | ||
{ | ||
"name": "transfer", | ||
"paramaters": [], |
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.
parameters
NeoContractABI.mediawiki
Outdated
<pre> | ||
{ | ||
"name": "refund", | ||
"paramaters": [] |
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.
parameters
NeoContractABI.mediawiki
Outdated
} | ||
</pre> | ||
|
||
<code>name</code> is the name of the paramater, which can be any valid identifier. |
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.
parameter
NeoContractABI.mediawiki
Outdated
|
||
<code>name</code> is the name of the paramater, which can be any valid identifier. | ||
|
||
<code>type</code> indicates the type of the paramater. It can be one of the following values: <code>Signature</code>, <code>Boolean</code>, <code>Integer</code>, <code>Hash160</code>, <code>Hash256</code>, <code>ByteArray</code>, <code>PublicKey</code>, <code>String</code>, <code>Array</code>, <code>InteropInterface</code>. |
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.
parameter
NeoContractABI.mediawiki
Outdated
|
||
<code>type</code> indicates the type of the paramater. It can be one of the following values: <code>Signature</code>, <code>Boolean</code>, <code>Integer</code>, <code>Hash160</code>, <code>Hash256</code>, <code>ByteArray</code>, <code>PublicKey</code>, <code>String</code>, <code>Array</code>, <code>InteropInterface</code>. | ||
|
||
===ParamaterType=== |
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.
ParameterType
NeoContractABI.mediawiki
Outdated
|
||
===ParamaterType=== | ||
|
||
ParamaterType enum has the following values: |
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.
ParameterType
NeoContractABI.mediawiki
Outdated
!description | ||
|- | ||
| Signature | ||
| A signature of transaction or block which is generated by user. |
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.
A signature of a transaction or block which is generated by the user.
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.
Maybe this sentence can be rephrased in a more easy to read manner?
NeoContractABI.mediawiki
Outdated
|
||
==Rationale== | ||
|
||
We assume the Application Binary Interface (ABI) is strongly typed, known at compilation time and static. No introspection mechanism will be provided. We assert that all contracts will have the interface definitions of any contracts they call available at compile-time. |
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.
How about changing:
We assert that all contracts will have the interface definitions of any contracts they call available at compile-time.
To:
At compile-time, we assert that all contracts will have the same interface definition. This is also true for any potential other contracts said contracts call.
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.
Of course I meant "compile-time", I updated my comment...
NeoContractABI.mediawiki
Outdated
Author: Erik Zhang <erik@neo.org> | ||
Type: Standard | ||
Status: Draft | ||
Created: 2017-9-13 |
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.
How about using YYYY-MM-DD
format? :) Thus changing 2017-9-13
to 2017-09-13
if this date ever were to be parsed by some program?
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 spec should probably specify the structure of the entry point parameters for Smart Contracts that are compliant with the spec. Currently the spec describes a set of functions and their expected parameters, but it's not clear from the ABI how one would actually invoke the entry point for a given function. Should the function name be the first parameter? The last? Seems like it should be the first parameter, but it would be good to call that out explicitly. |
nep-3.mediawiki
Outdated
| A string which is encoded in UTF-8. | ||
|- | ||
| Array | ||
| An array of objects. |
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.
Could you elaborate on what "objects" means here? It doesn't seem to refer to a standard type
@erikzhang I have a question perhaps in the scope of NEP-3, I don't know if people are already actually using it for automated processes, but we are (at Eco platform: https://eco.neocompiler.io). One small thing is causing a big issue to us (@vncoelho), perhaps it's just a mistake in C# ICO_Template (I will propose a fix for it), or perhaps we need to put more emphasis on a point here at NEP-3. When we compile C# ICO_Template and generate the ABI, method names are automatically listed (following the same C# syntax), for example, "Deploy" ABI is generated for C# "Deploy()" method. I think the compiler and ABI is doing the right job, however, when I try to invoke the method "Deploy" (our platform does this automatically), it won't work, because the actual string operation is "deploy". So, the ABI becomes useless to us. In my opinion, in the scope of NEP-3 we should emphasize (no need to change the text it's perfect, just a public understanding), that:
So, a proper fix would be to have the C# ICO_template having functions with the same capitalization as the op string names (which are already consistent to NEP-5 spec), just to allow the compiler to correctly and automatically generate the ABI. Do you agree? |
This is correct.
But I think the C# compiler should be improved instead (to use code annotations / comments, or have smarter derivation of operation name through code analysis) instead of forcing functions to have same naming as operation string? |
It already allows some annotations, however, they also do not exist on ICO template... ok, I'll propose some changes (one or the other). I will see if that conflicts with event names as well. |
Maybe we should make the compiler automatically turn the first letter of the method name into lowercase when generating the ABI? |
@erikzhang I thought about that haha I'm not a C# dev, but C++ and Java "standard" require methods to start lower case (and classes upper case). Isnt that the same for C#? |
C# methods starts with upper case. |
According to neo-project/proposals#12 display names for functions must match string abi calls.
@RavenXce and @erikzhang, it seems the better option is to use DisplayName to adjust function names, so C# programmers can keep C# standard, while making everything 100% compatible with ABI signatures :) |
An application binary interface (ABI) is the interface between two program modules, one of which is often a library and/or operating system and the other one is usually an application created by a regular programmer.
This NEP describes the ABI standards for NEO smart contracts.