Currently, UIntType has a Constructor that takes an UnsignedLong, which works mostly well.
However, in this hierarchy of calls, the UnsignedLong is converted into a hex-string so that it can be converted into a UnsignedByteArray.
In other places in the code (e.g., JSON deserialization), we start with a hex string, convert to an UnsignedLong, then pass this value up the constructor chain only to be converted back into a String and then to a ByteArray.
We should be able to make this more efficient, such as by creating a set of protected constructors in UIntType that allows a hex-string to be suppllied, and then coverted to an UnsignedByteArray, potentially skipping the conversion into an UnsignedLong.
However, to be safe, we should test a variety of inputs here to make sure that the intermediate conversion to UnsignedLong isn't actually doing something useful that's required before conversion to an UnsignedByteArray.
Currently,
UIntTypehas a Constructor that takes anUnsignedLong, which works mostly well.However, in this hierarchy of calls, the
UnsignedLongis converted into a hex-string so that it can be converted into aUnsignedByteArray.In other places in the code (e.g., JSON deserialization), we start with a hex string, convert to an
UnsignedLong, then pass this value up the constructor chain only to be converted back into aStringand then to aByteArray.We should be able to make this more efficient, such as by creating a set of protected constructors in
UIntTypethat allows a hex-string to be suppllied, and then coverted to anUnsignedByteArray, potentially skipping the conversion into anUnsignedLong.However, to be safe, we should test a variety of inputs here to make sure that the intermediate conversion to
UnsignedLongisn't actually doing something useful that's required before conversion to anUnsignedByteArray.