I know that Spec and the changes coming to Clojure 1.9 I see that namespace qualified keys have gained some focus. I understand the motivations for this and support it.
The one barrier that is coming up for me is in the use of Clojure records (and perhaps deftype types too). We use records fairly heavily in some of our applications for a few reasons. (Some of this is for performance, some for instanceof support for some Java-style libraries we use, some is for better documentation of expected fields used repeatedly, and also we have used them to extend different protocol implementations to.) I believe in some older talks a selling point of records, which I agree with, is they could be added later with not much change if you were already using maps throughout with those keys. This is due to record participating in the map abstractions. So how can namespace qualified keys and the use of records intermix? Even if I am using maps combined with records where the record and maps share some common keys/fields, if the maps were qualified, they'd be incompatible I believe. If records keys were qualified it would obviously raise a little question on how they blend with the emitted Java class field names I'd be curious to hear if there is any work or thought on this. Or maybe I can qualify keys and interoperate with records already and I just haven't noticed? -- 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.