Consider introducing a type alias for NamespaceVersion

[rootulp]

[optional] What do you think about type aliasing here? i.e., defining a distinct type for the NamespaceVersion, this will facilitate future refactoring and debugging

Originally posted by @staheri14 in celestiaorg/celestia-app#1529 (comment)

[rootulp]

FWIW the same approach can be adopted by ShareVersion

[staheri14]

I believe that type aliasing is important for several reasons. Firstly, it can greatly aid in the process of refactoring code (discussed before). Also, if we define a variable as uint8, it may appear arbitrary and not be immediately clear how it fits into the overall protocol-level decision. As the codebase grows and more variables of type uint8 are defined, it can become increasingly difficult to keep track of which ones correspond to a specific type, such as NamespaceVersion or ShareVersion.

Secondly, type aliasing allows us to implement helper functions that are specific to a particular type, such as a validity check for the NamespaceVersion type (we may also need to define custom math operations over them, like comparison, subtraction, etc.). By contrast, if we were using uint8, it would be much more difficult to ensure that the value being checked corresponds to the intended meaning. For example, uint8 could represent an index, a temperature, a time value, or any number of other things. Type aliasing helps to clarify the semantic of the data type and disallows misuses, making the code more robust and easier to maintain over time.

[NishantKoyalwar]

hii @staheri14 @rootulp , i am interested on working on this issue but i think we should use type declaration type NamespaceVersion uint8 (exactly like enum are used in golang) instead of type aliases (type abc = xyz) they usually serve purpose of depricating types or helpful in refactoring

let me know what do you think of this and i will create a new pr

[staheri14]

Using this form type NamespaceVersion uint8 is exactly what I meant by aliasing. 👍

[Wondertan]

A quick note that aliasing in Golang is slightly different from new type definition. https://yourbasic.org/golang/type-alias/

Might worth reconsidering which of the approaches suites the needs better