Some suggestions for modification to NEP-25

[erikzhang]

Old:

{
  "type": "Integer",
  "namedtype": "name",
  "length": 32,
  "forbidnull": true,
  "interface": "IIterator",
  "key": "Integer",
  "value": {},
  "fields": []
}

My suggestion:

{
  "base": "Integer",
  "name": "name",
  "length": 32,
  "nullable": false,
  "interface": "IIterator",
  "keytype": "Integer",
  "elementtype": {},
  "fields": []
}

Furthermore, I believe that the extendedreturntype and extendedtype fields should be simple strings used to reference the type descriptors in namedtypes.

[roman-khimov]

1. type/base breaks NEP-14 compatibility.
2. The default for booleans is false and by default (and by NEP-14) NULL can be used everywhere, so nullable is inconvenient.
3. All the other renamings are pure stylistic, not worth the trouble to me.

[erikzhang]

But NEP-14 does not have namedtypes, and these are fields unique to namedtypes, aren't they?

And what about this?

Furthermore, I believe that the extendedreturntype and extendedtype fields should be simple strings used to reference the type descriptors in namedtypes.

[roman-khimov]

But NEP-14 does not have namedtypes, and these are fields unique to namedtypes, aren't they?

No, parameters can have these extensions listed directly, like

            {
               "extendedtype" : {
                  "value" : {
                     "type" : "Hash160"
                  },
                  "type" : "Array"
               },
               "name" : "arrayOfHash160",
               "type" : "Array"
            }

Furthermore, I believe that the extendedreturntype and extendedtype fields should be simple strings used to reference the type descriptors in namedtypes.

Named types are designed for structures and they don't make a lot of sense in many other contexts like the one above with an array of hashes, or array of integers, or a map of strings to strings, or an integer that has a fixed width, or an iterator with string values, etc. All of them have no real type names in contracts, they don't deserve any in manifests as well.

[erikzhang]

Named types are designed for structures and they don't make a lot of sense in many other contexts like the one above with an array of hashes, or array of integers, or a map of strings to strings, or an integer that has a fixed width, or an iterator with string values, etc. All of them have no real type names in contracts, they don't deserve any in manifests as well.

In this way, we don't need extendedtype and extendedreturntype field. We can simply mix the fields of the ExtendedType structure into Parameter.

[roman-khimov]

We also have named types. And method definitions have quite some number of properties not related to types. That's why there is one structure defined for every use case, this makes reusing it easier (less error-prone as well).

[erikzhang]

Let me summarize: We include fields like length and forbidnull in the Parameter structure. The ExtendedType structure is only used for namedtypes.

[erikzhang]

{
  "methods": [
    {
      "name": "getAccount",
      "offset": 0,
      "safe": true,
      "parameters": [],
      "returntype": "Account"
    },
    {
      "name": "getAccounts",
      "offset": 100,
      "safe": true,
      "parameters": [],
      "returntype": {
        "type": "Array",
        "valuetype": "Account"
      }
    }
  ],
  "namedtypes": {
    "Account": {
      "type": "Array",
      "name": "Account",
      "forbidnull": false,
      "fields": [
        {
          "name": "id",
          "type": "Hash160"
        },
        {
          "name": "balance",
          "type": "Number"
        }
      ]
    }
  }
}

The key point here is that we can make the returntype accept both a string and a Parameter structure. This ensures perfect compatibility with NEP-14 without complicating the standard.

[roman-khimov]

returntype accept both a string and a Parameter structure

It's harder to parse. A string is easy. A structure is easy. A mix of them is always a problem and requires additional attention/code. A separate structure is more convenient both for manifest parsing and bindings generation (just to remind, that's what we're aiming for --- ability to generate language-specific bindings for any contract based on its manifest).

perfect compatibility with NEP-14

That's what we have with current NEP-25, both ways:

• compilers producing NEP-14 manifests are still 100% valid, users can compile contracts and deploy to post-Faun networks
• any tools parsing NEP-14 manifests are still 100% valid for NEP-25 if they ignore additional fields, old fields have exactly the same meaning as before

The standard was discussed for quite some time and these properties were there since the beginning, I see no value in changing it.

[shargon]

@erikzhang Do you think Roman's arguments are solid enough to close this issue and continue with the current implementation?

[erikzhang]

Please wait while I write a new version of the ABI standard.