Why don’t just do simple and no surprise thing first (return cljs.core/UUID), and make optimizations optional?
Transit’s UUIDs are not even performance optimization: every time you want to compare/hash/equiv them, this code is called https://github.com/cognitect/transit-js/blob/master/src/com/cognitect/transit/types.js#L286-L298. toString is very much not free on transit’s UUIDs, but it _is_ free on cljs UUIDs. Additional time is also spent on read for _every_ instance of UUID to convert it to hi/low bit format — and for most people out there for most of the times, they will never get any benefits from that. A lot of effort has been spent already, and you can spend some more, making it look like these two are in fact the same type (in the end, they will never be anyways), but I don’t see any justification for that. What’s that important reason that explains why we’re making things more complicated that they should be? On Sun, Sep 27, 2015 at 9:38 PM David Nolen <[email protected]> wrote: > Transit's UUID stores the byte representation and provides methods for > accessing the lower and higher bits, cljs.core's UUID is just a simple > wrapper around a string. > > Transit provides a uuid? predicate for this reason. Though perhaps it > would be better to provide a marker protocol in cljs.core instead for this > case a la IRecord and test this in cljs.core/uuid? > > > David > > On Sat, Sep 26, 2015 at 6:13 PM, Jamie Orchard-Hays <[email protected]> > wrote: > >> Why *does* Transit have another UUID type? I was surprised to see that. >> >> >> > On Sep 26, 2015, at 6:06 PM, Nikita Prokopov <[email protected]> >> wrote: >> > >> > Having two UUID types around is not a good idea. Transit shouldn’t have >> its own type, but since it’s there, I recommend re-configure transit reader >> to always read native CLJS UUIDs: >> > >> > (defn read-transit-str [s] >> > (t/read (t/reader :json { :handlers {"u" cljs.core/uuid} }) s)) >> > >> > You‘ll save yourself A LOT of headache, trust me >> > >> > -- >> > Note that posts from new members are moderated - please be patient with >> your first post. >> > --- >> > You received this message because you are subscribed to the Google >> Groups "ClojureScript" group. >> > To unsubscribe from this group and stop receiving emails from it, send >> an email to [email protected]. >> > To post to this group, send email to [email protected]. >> > Visit this group at http://groups.google.com/group/clojurescript. >> >> -- >> Note that posts from new members are moderated - please be patient with >> your first post. >> --- >> You received this message because you are subscribed to the Google Groups >> "ClojureScript" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at http://groups.google.com/group/clojurescript. >> > > -- > Note that posts from new members are moderated - please be patient with > your first post. > --- > You received this message because you are subscribed to a topic in the > Google Groups "ClojureScript" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/clojurescript/_B52tadgUgw/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/clojurescript. > -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/clojurescript.
