I'll attempt an argument for returning the record's type in another way: I
can always get a PersistentArrayMap from select-keys, if I want. Just add
(into {} ...) to the chain. I cannot, however, retain the record type
because select-keys *makes the decision for me*.
In other words, letting select-keys return the key/value pairs in the type
I passed it, I retain control, rather than watching it be yanked from me.
(I also came across this thread because select-keys' return value surprised
me. What's worse, though, there's no simple way to resolve it without
re-introducing a constructor function in the middle of my flow.)
On Sunday, November 3, 2013 2:46:40 PM UTC-7, dcj wrote:
>
>
> On Nov 2, 2013, at 9:27 AM, Mark Engelberg <mark.en...@gmail.com
> <javascript:>> wrote:
>
> I seem to be a relatively lone voice thinking it makes sense to preserve
> the type of the map, and honestly, I'm not going to lose any sleep if this
> patch is never actually implemented, but here's my two cents on the
> "optimal" design for records.
>
> Earlier in the thread, I mentioned two mental models about how select-keys
> works. Even though the actual implementation involves starting from an
> empty map and building back up, I think the behavior of select-keys should
> mimic the mental model of discarding irrelevant keys.
>
> The two mental models predict somewhat differently what would happen when
> working with records. Records can hold additional keys. So imagine
> someone dumps a whole lot of additional keys, and then wants to "recover"
> the original, true record, by calling select-keys with the original keys in
> the record. I think this is a use case worth supporting. This corresponds
> to the mental model of discarding unwanted keys.
>
> To implement this for records:
> If any of the original record keys do not appear in the selected keys,
> then, as with dissoc, we must revert back to a map as there is no valid way
> to represent this as a record.
> Otherwise, maintain the record type -- the core record contents are
> preserved, and essentially you only need to call select-keys only on the
> extended map of extra keys stored in the record.
>
>
> I agree 100% with Mark’s comments above.
> This is exactly the model I would expect select-keys to have.
>
> Conceptually, this is how I imagine select-keys should work:
>
> (defn select-keys++
> "Returns a new map of the same (hashed/sorted) type,
> that contains only those entries whose key is in keyseq"
> [map keyseq]
> (apply dissoc
> map
> (clojure.set/difference (set (keys map))
> (set keyseq))))
>
>
> I am not saying that this would be the best , or even a good,
> implementation.
>
> Like Mark, I am not going to lose any sleep about this either, but I was
> using Mark’s data.priority-maps the other day,
> did a select-keys to winnow down my priority-map, and was surprised by the
> result.
> Perhaps I should not have been surprised….
> In preparing this email, I carefully re-read the doc strings for both
> dissoc and select keys:
>
> (defn dissoc
> "dissoc[iate]. Returns a new map of the same (hashed/sorted) type,
> that does not contain a mapping for key(s).”
>
> (defn select-keys
> "Returns a map containing only those entries in map whose key is in keys"
>
>
> Clearly dissoc makes the promise to return a map of the same type that
> select-keys doesn’t.
> A potential non-code change to select-keys might be to emphasize that the
> return map will be
> a hash-map, regardless of the kind/type of input map.
>
> Don
>
>
>
> On Sat, Nov 2, 2013 at 8:49 AM, Andy Fingerhut <andy.fi...@gmail.com
> <javascript:>> wrote:
>
>> I attached another patch to the ticket. It builds up the answer from the
>> empty map {} if the argument is a record (as the current select-keys does),
>> but from (empty map) if it is not a record, so it will preserve sortedness
>> of the argument. Not sure if there are any other cases that are a problem,
>> or if it does what everyone would expect, but it should be closer.
>>
>> http://dev.clojure.org/jira/browse/CLJ-1287
>>
>> Andy
>>
>>
>> On Sat, Nov 2, 2013 at 6:07 AM, Alex Miller <al...@puredanger.com
>> <javascript:>> wrote:
>>
>>> > One other point:
>>> > Sometimes people use sorted maps and array maps specifically for
>>> scenarios in which the keys are not hashable and therefore hash maps would
>>> not apply. Dumping the contents into a regular map in such cases doesn't
>>> make much sense.
>>>
>>> Everything is hashable, not sure what a non-hashable key means. Array
>>> maps use the hash of the key to determine the array bucket. If you get the
>>> hash code of a sorted map, it will get the hash of all keys and values.
>>>
>>> --
>>> --
>>> 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 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 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/d/optout.
