Welcome! Please see the About page for a little more info on how this works.

+1 vote
in Clojure by

ClojureScript has {{uuid}} and {{random-uuid}} functions. These are handy to have in ClojureScript, and I think would be useful also in Clojure to improve code portability. Is there interest in a patch for this?

8 Answers

+1 vote
by

Comment made by: wilkerlucio

(link: ~alexmiller) I understand the idea to make it fully compatible would be nice. But been honest, as a user that writes a lot of CLJC, if we just had the uuid and random-uuid (especially the later) would solve 99% of my UUID needs, and I guess for most people is the same. Can't we start by just adding those that are a sure win for everyone using, and leave the detailed designed UUID thing on a separated ticket?

0 votes
by

Comment made by: alexmiller

I think the main reason to do this would be portability. It would make most sense to generate java.util.UUIDs - is that harmonious with what is being done in ClojureScript? That is, could the same code for creating and using uuids work on both platforms? If not, then there might not be a good reason to do so.

0 votes
by

Comment made by: desk@danielcompton.net

It would make most sense to generate java.util.UUIDs - is that harmonious with what is being done in ClojureScript?

ClojureScript defines it's own UUID type, as one doesn't exist in JavaScript. https://github.com/clojure/clojurescript/blob/dd589037f242b4eaace113ffa28ab7b3791caf47/src/main/cljs/cljs/core.cljs#L10088-L10128. I'm not quite sure what you mean by harmonious.

That is, could the same code for creating and using uuids work on both platforms?

The CLJS UUID doesn't support all of the methods of the Java UUID, but the important things are there (equivalence, constructing from a string, printing to a string) and they would be enough to significantly improve portability when working with UUID's.

0 votes
by

Comment made by: bronsa

both clojure and clojurescript have uuid tagged literals, that should be good enough for interop

0 votes
by

Comment made by: alexmiller

I'm aware of that, just wondering if there are any functions you might invoke on a uuid that would need some portable equivalent, like the stuff in http://docs.oracle.com/javase/8/docs/api/java/util/UUID.html.

0 votes
by
_Comment made by: desk@danielcompton.net_

Most of the extra methods here are useful for distinguishing between multiple types of UUID's, or getting information out of time based UUIDs.


clockSequence() - time based
compareTo(UUID val) - not sure if equivalent required?
boolean    equals(Object obj) - no action required
static UUID    fromString(String name) - constructor
long    getLeastSignificantBits() - not sure how important these two are
long    getMostSignificantBits()
int    hashCode() - no action required
static UUID    nameUUIDFromBytes(byte[] name) - is this useful/important?
long    node() - only useful for time UUID
static UUID    randomUUID() - would implement this
long    timestamp() - time based UUID
String    toString() - no action required
int    variant() - for distinguishing between different types of UUID's
int    version() - for distinguishing between different versions of UUID's



I could potentially see an argument for time based UUID's being included in a patch here too, but I'm not sure if they are used enough to be worth it, and they'd need to go into CLJS, e.t.c.

There is use of some of these methods in Clojure code:
https://github.com/search?l=clojure&q=.getLeastSignificantBits&type=Code&utf8=✓
https://github.com/search?utf8=✓&q=%22.nameUUIDFromBytes%22+language%3Aclojure&type=Code&ref=searchresults

But less than the literal constructor by a factor of ~100:
https://github.com/search?utf8=✓&q=java+util+UUID+language%3Aclojure&type=Code&ref=searchresults (this is a flawed search query, but the best I could do).
0 votes
by

Comment made by: alexmiller

I guess my greater point is: rather than consider just the functions uuid/random-uuid, let's consider the problem to be: how can we add portable uuid support in Clojure/ClojureScript? That's a lot more work, but a lot more valuable in my opinion.

So would also want to consider (some of these exist already, but may not have been tested for portability):
- construction
- printing - print, pr, pretty print
- reading
- hash code
- conversion to/from bits
- conversion to/from string
- extraction of components

And then I think it's worth considering how much of this should be in core vs in a data.uuid or something.

I think it's probably better to work it off a design page than here (this ticket is but one unit of the greater problem). Perhaps http://dev.clojure.org/pages/viewpage.action?pageId=950382 could suggest some pointers.

0 votes
by
Reference: https://clojure.atlassian.net/browse/CLJ-1925 (reported by desk@danielcompton.net)
...