RFC: Rename locking instructions #39
Conversation
franciscoaguirre
left a comment
franciscoaguirre
left a comment
There was a problem hiding this comment.
My main concern with this is that we want the wider ecosystem to adopt XCM, and the main terminology used is asset locking/unlocking. Imposing a new term for this could make adoption harder.
|
|
||
| ## Impact | ||
|
|
||
| This change will impact all XCM code that uses the lock instructions, constituting a breaking change. All code should be updated to use these new names. Failure to update the code could result in errors. |
There was a problem hiding this comment.
We should keep in mind this will probably go to a new XCM version, which means the migration is pretty straightforward.
There was a problem hiding this comment.
It is a breaking change in the API level, but not on the transaction layer, since the codec indices for these instructions did not change, nor did the instructions parameters change.
I do also think that keeping the old terminology is confusing once we updated from locking -> freezing in FRAME. |
|
The XCM spec shouldn't care about FRAME. We may want to do the rename but the reason shouldn't be because FRAME did it. If anything, it is the FRAME should honor XCM's naming convention. |
Summary
This RFC proposes renaming several XCM instructions to align with changes in Substrate naming.
The following instructions and error are affected:
Instructions:
LockAsset->FreezeAssetUnlockAsset->ThawAssetNoteUnlockable->NoteThawableRequestUnlock->RequestThawError:
LockError->FreezeError