Get contract name in ToJson

[superboyiii]

Related: neo-project/neo-modules#378
Partly support: neo-project/neo-modules#355
Enable get name in ToJson.

[roman-khimov]

We might want to extend manifests to include some name for all contracts, btw. Neo 2 had that metadata and it allowed contract explorers to show something more meaningful than just hashes.

[superboyiii]

We might want to extend manifests to include some name for all contracts, btw. Neo 2 had that metadata and it allowed contract explorers to show something more meaningful than just hashes.

Yes, might add it later.

[superboyiii]

Done

[superboyiii]

@shargon Shall we merge?

[shargon]

Please take a look, I don't like to make difference between native and not native.

[erikzhang]

May I ask why you need to get the name of the contract in json? Isn't this public information? They can be hard-coded into the SDK.

[roman-khimov]

I think any contract should have a name.

[erikzhang]

I think any contract should have a name.

I also think so. But how should they display their names? Some contracts use the name() method, and some use the manifest. If all contracts are required to have a name, then a unified way must be used to display the names.

[superboyiii]

May I ask why you need to get the name of the contract in json? Isn't this public information? They can be hard-coded into the SDK.

As neo-project/neo-modules#355 said, although hash is necessary, name/ID is more convenient to remember as one of the contract infos. I think we have duty to make it more friendly for development. And as @roman-khimov said, maybe we could make name and contact as required when deploying as neo2 did (neo2 get name in contract state from what they input when deploying) or we could make a check on name from manifest to ensure it contains name and return error msg when it's null.

[superboyiii]

Please take a look, I don't like to make difference between native and not native.

Agree

[roman-khimov]

Some contracts use the name() method, and some use the manifest

Manifests are probably more appropriate for this, both native and non-native contracts could have a field there for name.

[erikzhang]

Manifests are probably more appropriate for this, both native and non-native contracts could have a field there for name.

Then we should modify NEP-5 and other standards, and remove the name() method.

[shargon]

I think that it will be easier with name method, I can change the code to execute name if we are agree

[roman-khimov]

name() method requires spawning a VM, running some code and then dealing with the output, to me it's a bit harder than getting data from a field in the manifest. At the same time, name() is something available to other contracts unlike manifest, but that can be solved with some System.Contract.GetManifest syscall probably.

[Tommo-L]

although hash is necessary, name/ID is more convenient to remember as one of the contract infos.

Wouldn't it be more convenient to use NNS.

For me, we'd better keep name method, like NEP-5/11, we already have symbol, decimals methods. If just move name method to manifest file, it doesn't look consistent.

BTW, multiple contracts can also have the same name, and a query by name is not very reliable.

[Tommo-L]

Now, we can move on

[shargon]

Now, we can move on
yes, we can take it from the manifest

[superboyiii]

@roman-khimov @shargon @erikzhang Please review again.

[erikzhang]

The name is included in the manifest, and I think we don't need to add it to the top level of the json.

[superboyiii]

The name is included in the manifest, and I think we don't need to add it to the top level of the json.

Agree. I'll close this.