Thanks for the response and giving me some understanding in the thought process behind this!
I'm happy that Spec is still offering support for unqualifed keys to fit use-cases like this in records. I do think it would be cool to see something come out of the "implicit" namespace already associated to a record so that the keywords could be used in a qualified way, but obviously we'll have to wait and see how that one may or may not play out. It's good to hear that the thought has came up though! On Saturday, June 11, 2016 at 11:57:38 AM UTC-5, Alex Miller wrote: > > This is a good question and one we've discussed a bit. You can use the > existing s/keys with :req-un and :opt-un to spec the (unqualified) keys of > a record - there's an example of this in the guide at > http://clojure.org/guides/spec. So that's the short-term current answer. > > However, there are potentially other things that could be done, either to > make working with unqualified keys easier (for example in the case where > spec names and unqualified key names didn't match) or in leveraging the > (implicit) namespace already associated with a record via the record class > itself. So, this is an area still potentially open for more work. > > I think deftype is not an issue as you don't generally have keyword field > access in deftype like you do with defrecord. > > > On Saturday, June 11, 2016 at 11:02:57 AM UTC-5, Mike Rodriguez wrote: >> >> 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.
