NEP 22: Contract Update Standard

[superboyiii]

Close: #135

[ixje]

LGTM

[roman-khimov]

It'd be nice to have this, I'd change our examples to use this standard interface.

[erikzhang]

Add _initialize?

[roman-khimov]

_initialize is something different to me, not directly related to deploy/update. Maybe it's in some other document (but I wasn't able to find it on https://docs.neo.org/) or other NEP.

[superboyiii]

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

[roman-khimov]

NEP-22:

provide systems with a generalized interaction mechanism for smart contract initial deploy, update and destroy.

I don't see _initialize being a part of this NEP.

[erikzhang]

I don't see _initialize being a part of this NEP.

I'm not sure if it should be part of this PR, but obviously it should be included in a document.

Also, don't forget the verify method.

[superboyiii]

I don't see _initialize being a part of this NEP.

I'm not sure if it should be part of this PR, but obviously it should be included in a document.

Also, don't forget the verify method.

Added.

[superboyiii]

@erikzhang @roman-khimov Is it OK?

[roman-khimov]

It's a method soup now to me. I'd rather have separate NEPs for _initialize, _deploy and verify (three NEPs, seems to be perfectly fine to me, they are different unrelated things) and one for update/destroy. I want to be able to specify "NEP-XYZ" in SupportedStandards and expect all the tooling around to understand that this contract has standardized update/destroy method pair that can be interacted with. "NEP-22" doesn't give this meaning right now.

[ixje]

_initialize is something different to me, not directly related to deploy/update. Maybe it's in some other document (but I wasn't able to find it on https://docs.neo.org/) or other NEP.

I can kind of see the relationship. update can call _deploy which in turn can call _initialize again. Ideally there would be a flow diagram included to make it clear. verify on the other hand seems totally unrelated and worthy of a separate document if we're splitting anyway

[roman-khimov]

I can kind of see the relationship

Is it related? Probably so. Can be it be used without all the other things? Sure it is. Can all the other things in this proposal be used without _initialize? Sure they are. We can have as many standards as we need and they can be related, but different standards for different things. NEP-XYZ in SupportedStandards should have some specific meaning. And SupportedStandards can have as many NEP-X, NEP-Y, NEP-Z as needed.

[EdgeDLT]

And SupportedStandards can have as many NEP-X, NEP-Y, NEP-Z as needed.

I agree in principle with the idea of having independent standards. But I suspect there are many others like myself who also have a mental block at the future thought of these long lists of numbers with no meaning. Maybe we could package them together under a standard group, but at that point, is it that much different from what we have now?

[superboyiii]

@roman-khimov Done

[roman-khimov]

Editorial nitpicks, but OK otherwise.

[superboyiii]

@roman-khimov Done

[AnnaShaleva]

Sorry for this minor fix, I couldn't resist, and now all previous approvals are gone. @Jim8y, @roman-khimov, need your approvals one more time.

[Jim8y]

Sorry for this minor fix, I couldn't resist, and now all previous approvals are gone. @Jim8y, @roman-khimov, need your approvals one more time.

@AnnaShaleva That is totally ok to comment on minor fixes, you are the strongest sheld we have to ensure eveything works properly, your concern definately will be addressed after the merge. Just approve an NEP takes too long while fixing minor issues can be in another track, along with file name/nep number/readme.