> I guess what I'd like a mode where I can say "act like read/pr" and> for > deep-freeze to ignore metadata, refs and atoms.
I'm still not sure I'm getting this argument though. In its current form, deep-freeze makes an attempt to preserve as much information as it can. In the specific case of STM/metadata it happens to preserve a little more information than read/pr. Now I can understand the desire for a drop-in replacement, but why would you be calling read/pr on refs and atoms in the first place if it'd be throwing an exception? Presumably you're thinking here in terms of processing Clojure data outside of your control? I just worry that attempting to keep parity with read/pr will require undue effort in the long-term. For example, the ref/atom handling is obviously different to read/pr now: but maybe other types are different in subtle ways too? It'd be necessary to introduce a consistency test between the two, and that would require maintenance down the line. And what would happen when performance concerns conflict with consistency ones? Sure, it'd be possible- but I'm just wondering how widespread the desire is that serialization be one-to-one with read/pr? Will people often be switching back and forth between the two? Why? (Sincere question- maybe I'm missing something!) (Just my 2c BTW: it's Timothy's call) -- Peter -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
