-
Notifications
You must be signed in to change notification settings - Fork 55
Generate ABI together with AVM #34
Comments
I think its a good idea! Probably related to this new functionality here: #31 |
Here is an example of ABI output from NEO C# compiler for an ICO template |
It would be nice to have some advances here... although I don't think it's easy to do :) |
I'm guessing the biggest hurdle is going to be supporting type hints. @saltyskip can you also link the C# template that matches this ABI output? |
|
Apologies for the direct code post, It is the template on neocompilereco, and I could not find where it is actually hosted 😅 |
Is it me or is the ABI output missing an entry for public static readonly byte[] Owner = "AK2nJJpJr6o664CWJKi1QRXjqeic2zRp8y".ToScriptHash(); as it looks to output all public accessors. Perhaps I'm a bit skeptical, but is this ABI output not kind of useless without knowing a mapping of "operation name => function"? e.g. the operation "deploy" maps to It also seems to force you into using a fixed Main signature and implementation structure of public static Object Main(string operation, params object[] args)
if (operation == 'name') return Name() which is severely limited due to the 16 objects max array length of args. Any thoughts? |
I just noticed that the sample ABI doesn't follow NEP3 sample ABI:
NEP3 suggestion
I believe we need more alignment before this can be considered. |
I think that is correct because it only outputs functions not publicly accessible static variables. Although that would be a nice addition. @igormcoelho do you do any custom formatting on neocompiler eco? |
From my testing it looks like NeoCompiler Eco takes the ABI output from the neon compiler with all the function names, then assumes that the operation name will be the same name (only in camelCase) when it comes time to choose one to invoke. Of course, there's no guideline for function vs operation naming in NEP-3 so a lot of contract authors are going to name their operations one thing and their corresponding functions another, and their generated ABI will be fairly useless to NeoCompiler Eco or other tools that parse the ABI. For neo-boa, I like the idea of using Pythonic type hints and building the ABI based on any function or event definition that contains hints, using the name of the function verbatim as the operation name. Then, we need to amend NEP-3 with guidance to require any operation that is meant to be included in the ABI have a function name with its exact match. Given the top-down-from-Main invocation pattern built in to the Neo VM I don't see a perfect way to solve the problem without requiring some diligence on the part of contract authors, but at least this way it will at least be easy enough for contract authors to implement after some light reading. Edit: I see Erik had replied in the NEP-3 PR to the issue of function names and case with the following: C# methods starts with upper case. While you can certainly write a valid C# function name that starts with lower-case, it is technically part of the C# convention to use PascalCase for everything except parameter names. So I doubt he'll want to amend NEP-3 to suggest making a C# contract use However the C# compiler could be modified to automatically switch the ABI function names to camelCase instead of relying on the parser to do so, at least this way the different compilers could be made to be consistent in their ABI output if nothing else. |
Hi! I strongly appreciate neo-boa project, and I just wonder if you plan to generate an Application Binary Interface (ABI) json description of the compiled functions (parameters/return types) together with the .avm. This is an interesting feature from NEO C# compiler.
Best regards!
The text was updated successfully, but these errors were encountered: