On Friday, November 1, 2013 5:57:08 PM UTC-5, puzzler wrote: > > Having select-keys on records returning regular maps is *not* inconsistent > with preserving the "type" of map in the sense of sorted-map, priority-map, > etc. > > Here's why: > > If you think of select-keys as dissoc'ing all the irrelevant keys, that > would preserve the type of sorted-map, priority-map, but it would also turn > a record into a regular map (because as soon as you dissoc a required key > from a record, it turns into a plain map). >
The "irrelevant keys" would be the (infinite) complement of the set of specified keys, so this wouldn't work. If you think of select-keys as emptying out *all* the keys, and then > building back up with the selected keys (a more accurate representation of > what's going on under the covers), it still lends itself to exactly the > same model. Emptying out the keys preserves the type of a map, but > converts records to regular maps (because that's what already happens when > you get rid of required keys from a record). > I think of it as creating a new map and filling it with entries from any keys in the specified set that exist in the map (which is essentially what it does now). My bias is purely that I'm used to and comfortable with that behavior. Altering an existing function like select-keys is going to be harder to get accepted if it breaks existing code and that seems possible with the suggested alternative (certainly around records for now and possibly around performance). Instead, what if this was a new operation? Perhaps broader in scope would be a function that takes a map and a filter function (on key/value/both?) in that it filters a map based on a function of key/value/or both. This links back to a prior discussion (possibly on clojure-dev, can't remember now) about providing a richer set of operations that take and return maps. A similar function that does the inverse (removes based on a function) is another possibility - I see both of these re-implemented in many code bases in a variety of forms. I personally would love to have a richer set of built-in map-oriented functions comparable to the seq functions but with awareness of key-value entries and optimized for performance in those cases. Would require some serious "hammock" time to determine the right set of fns. Whatcha think? So, I think the behavior that Cedric described is exactly what mental > models would predict. > > Alex Miller has said that he thinks of it as just nebulously selecting > some sort of undefined subset of the map, but I think that's far too vague > to base the design on. I think the above two mental models are the ones > that someone would settle on if they spent a few seconds trying to think > about how it's probably implemented. Both predict the same behavior, and > that's the "principle of least surprise" we should be targeting. > > > On Fri, Nov 1, 2013 at 2:02 PM, Michael Gardner > <gard...@gmail.com<javascript:> > > wrote: > >> On Nov 1, 2013, at 14:18 , Mark Engelberg >> <mark.en...@gmail.com<javascript:>> >> wrote: >> >> > I'm sure it's possible to imagine both needs, but if you have have a >> sorted-map, and you do a select-keys, don't you think the "principle of >> least surprise" is for it to stay a sorted-map? >> >> I'm not sure about that, given how map and similar functions behave. And >> with the point Cedric raised about records, I think it's better to have >> consistent behavior (always return a regular map). >> >> -- >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clo...@googlegroups.com<javascript:> >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+u...@googlegroups.com <javascript:> >> 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+u...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/groups/opt_out. >> > > -- -- 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/groups/opt_out.
