Can we make a note about the word "token" in the CLI option #6.
We should move away from that word, when used to reference native assets.
Instead, define only public contract controlled assets as "tokens", in documentation.
But native assets should be defined as "private/native assets" in documentation, and maybe "asset/assets" in the CLI menu.
Example: token.bas is an example contract that emits native assets, this should be self referencing in its name, rather than describe 2 types of "tokens", describe them as 2 fundamentally different things, which they are. Assets and tokens.
This would necessitate a second contract example to cover how a "token" can function in DVM docs, along with renaming the existing example to fit the "native asset" descriptions.
This also allows for the removal of terms such as "private or public contracts", which can be confusing for people without prior knowledge of how the protocol works, allowing documentation covering Smart Contracts themselves to be clearly explained on their own, sans assets or tokens.
It also appears that by separating these two elements using the described choice in language, the space would be opened to allow for clearer expansion of information/documentation on both subjects independently of each other, down the road.
In pursuit of clear language:
Can we make a note about the word "token" in the CLI option #6. We should move away from that word, when used to reference native assets.
Instead, define only public contract controlled assets as "tokens", in documentation. But native assets should be defined as "private/native assets" in documentation, and maybe "asset/assets" in the CLI menu.
Example: token.bas is an example contract that emits native assets, this should be self referencing in its name, rather than describe 2 types of "tokens", describe them as 2 fundamentally different things, which they are. Assets and tokens.
This would necessitate a second contract example to cover how a "token" can function in DVM docs, along with renaming the existing example to fit the "native asset" descriptions.
This also allows for the removal of terms such as "private or public contracts", which can be confusing for people without prior knowledge of how the protocol works, allowing documentation covering Smart Contracts themselves to be clearly explained on their own, sans assets or tokens.
It also appears that by separating these two elements using the described choice in language, the space would be opened to allow for clearer expansion of information/documentation on both subjects independently of each other, down the road.