Closed amn closed 2 years ago
FWIW, this has been discussed before.
bit of an "oxymoron" in OOP
If JS were a strongly OOP language, I might give more weight to this argument, but it's a blend of OOP, functional, and... well... whatever other coding paradigms people choose to layer onto of JS. There's plenty of prior art for factory methods like randomUUID()
, so I don't see the current approach as oxymoronic.
Lumping this into the crypto module
This was necessitated by the requirement that there be a cryptographic source of randomness, which is currently only available in contexts where crypto
is present. We tried lobbying for a Math.getRandomValues()
api at one point, to allow for a more general context for this, but that effort fizzled out. Ergo... crypto
.
Fair points. It was late and I must have confused "create" with "crypto", there is admittedly no "create" in randomUUID
, so that's a non-factor. As for using the crypto
module, I guess if you choose to rely on cryptographically secure random value generation for generating UUIDs (CSRNGs aren't strictly required for UUIDs), then it makes sense to keep the generation procedure in the module, indeed. As for OOP, again, I see your point.
Whether it is required to use specifically a cryptographically secure RNG or not, is now beside the point since if crypto
implements its own UUID generator, it suffices to say it should indeed be accessed as a property of crypto
. Just as Math.random
has its uses, as does crypto.getRandomValues
, a good UUID can be generated by different methods, for instance utilizing a Mersenne Twister RNG, which isn't a CSRNG but is a PRNG that should be perfectly suitable for UUID generation, as far as I understand. But like I said, if crypto
implements UUID generation, then it should rightfully belong in the "module".
In light of there being a
URL
class, with parsing and what not and how a UUID is semantically a kind of datum, doesn't it make sense -- also to allow for extending the class(if applicable) et cetera -- to instead design this as a class of which objects can be instantiated?Some additional remarks:
create...
-named methods are a bit of an "oxymoron" in OOP, looking at the existence ofnew
. If you want to create an object, usenew ...
; we even havenew String(...)
so a UUID should easily make the cut and looks terser and clearer, in my opinion.Lumping this into the
crypto
module, while making a certain kind of sense from one or the other taxonomical perspective, is a bit of a miss as well -- UUIDs aren't just used for and in cryptography, and prefixing and thus effectively making it more verbose a class of "universal" identifiers seems to me unnecessary. Why not just put it in the global context, likeJSON
,URL
and some of the other similar classes?Not
new UUID(...)
-specific admittedly -- just as applicable tocrypto.randomUUID(...)
-- but either way a constructor likeUUID
should be open for extension through allowing additional options in the future, to accommodate for other UUID versions and variations and every other kind of parameter there would come a need for.