jetify-com
`fromUUID` and `TypeID.fromUUID` have inconsistent function signatures
Right now, when using TypeID.fromUUID, the signature is prefix, then uuid
TypeID.fromUUID(
"msg",
"848200C6-35FE-4209-A24B-CEE4D3D8847A"
)
With fromUUID export from typeid-js, the signature is uuid, then prefix.
I think it would be more consistent and less prone to errors, to have the same signature in both functions.
@skoshx are you primarily using TypeID class or the unboxed functions?
For now, TypeID.fromUUID is a completely separate thing from the unboxed fromUUID function. The signature difference is intentional, in that if the class TypeID is used, then no unboxed functions should be called. Vice versa.
Perhaps we need to namespace the unboxed version a little better 🤔
Right, I tried reading through the docs and I have no idea what the practical different between unboxed and using the TypeID class is. It seems to me that the only difference is that the unboxed alternatives offer a functional way to generate Type IDs?
Is there a reason why you shouldn't mix using the TypeID class and the unboxed alternatives?
Honestly, I thought that the TypeID class instance was calling the unboxed functions under the hood
@skoshx In most cases, TypeID class instance is calling the unboxed functions under the hood. But the two are completely different:
- The
TypeIDclass gives you a TypeID instance. The instance itself contain the prefix and suffix private fields. - The unboxed typeid functions gives you a string that has a
TypeIdtype (meaning it is really just a string, not an instance of a class). Every time you need access to its prefix/suffix you need to parse the string.
The unboxed version was introduced later, as the class implementation requires special serialization/deserialization step. We did not want to introduce a backward incompatible change, as many packages already depend on this.
Just to be clear, you don't want a TypeID class type and a TypeId string type mixed throughout your application. That is problematic - those two types cannot be compared. So, either stick with TypeID (class), or TypeId (unboxed)