Closed JoshuaSjoding closed 6 years ago
Both Parse
and ParseBytes
would be affected by this. I would refactor both functions to avoid repetition, and modify the test suite to include the new forms.
Would you be willing to make the same changes to pborman/uuid? These are essentially the same packages with the exception that the google one has:
type UUID [16]byte
while the (older) pborman one has:
type UUID []byte
At some point I should make one of these be implemented in terms of the other, but that will make one of them slightly slower.
github.com/pborman/uuid is being modified to leverage this package (it is the same code). I would like to see if there are any other common formats for UUIDs.
JoshuaSjoding@, would you care to do a code review of https://github.com/google/uuid/pull/37
I would like to prepare and submit a pull request that adds parsing support for two string forms that are not RFC-4122 compliant:
Braced
Non-dashed
The first is commonly generated by APIs and tools on the Windows platform.
The second is the hexadecimal encoding of the uuid without any further treatment.
Both assume the hexadecimal values to be in big-endian order, as per the spec. Any platform-specific byte-reordering would be left to the user.
The form of an input string can quickly be determined by its length, and the lengths are unique so parsing remains deterministic.