How about new UUID(...)?

[amn]

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 of new. If you want to create an object, use new ...; we even have new 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, like JSON, URL and some of the other similar classes?

• Not new UUID(...)-specific admittedly -- just as applicable to crypto.randomUUID(...) -- but either way a constructor like UUID 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.

[broofa]

FWIW, this has been discussed before.

[broofa]

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.

[amn]

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.

[broofa]

CSRNGs aren't strictly required for UUIDs

At this point, I can confidently say that was an unfortunate oversight by the original RFC authors. Using poor sources of randomness will invariably cause problems and effectively defeats the core premise of UUIDs.

[amn]

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".