The default has been established for some time and has been documented. It's now water under the bridge.
David On Sun, Sep 27, 2015 at 1:12 PM, Nikita Prokopov <[email protected] <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: > Sorry, I haven’t finished previous letter. > > If Cognitect depends so much on hi/low bits functions, you can _opt in_ to > using your own UUID type. Clean, simple and predictable by default, > opt-in optimizations when you need them. Are there any issues with that > approach? > > This issue ate a lot of my own time, since then, at least two other people > was hurt as well. It would be great to see it fixed. > > With respect, > Nikita. > > On Mon, Sep 28, 2015 at 12:08 AM Nikita Prokopov <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: > >> 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] >> <javascript:_e(%7B%7D,'cvml','[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] >>> <javascript:_e(%7B%7D,'cvml','[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] >>>> <javascript:_e(%7B%7D,'cvml','[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] >>>> <javascript:_e(%7B%7D,'cvml','clojurescript%[email protected]');> >>>> . >>>> > To post to this group, send email to [email protected] >>>> <javascript:_e(%7B%7D,'cvml','[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] >>>> <javascript:_e(%7B%7D,'cvml','clojurescript%[email protected]');> >>>> . >>>> To post to this group, send email to [email protected] >>>> <javascript:_e(%7B%7D,'cvml','[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] >>> <javascript:_e(%7B%7D,'cvml','clojurescript%[email protected]');> >>> . >>> To post to this group, send email to [email protected] >>> <javascript:_e(%7B%7D,'cvml','[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] > <javascript:_e(%7B%7D,'cvml','clojurescript%[email protected]');> > . > To post to this group, send email to [email protected] > <javascript:_e(%7B%7D,'cvml','[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.
