> Isn't the whole point of a struct that it guarantees that certain keys
> are present?
Oh, I agree -- dissoc on a struct-map would return a non-struct-map.
I'm not suggesting that struct-maps should be able to be dissociated
from one of their keys, I'm wondering whether it's better to return an
array-map or hash-map from dissoc rather than blow up.
(Or whether there should be a `without-keys` function that behaves
much like dissoc but works on any map, and have rename-keys and other
"implicit dissoc" functions use that instead. rename-keys on a struct-
map's core keys implies an abandonment of struct-ness, no?)
I suppose the question is "are struct-maps 'structs' or
maps?" (speaking ontologically). If they're structs, then it's happy
coincidence that the map get/assoc functions work on them, and
slightly confusing that they print as ordinary maps. If they're maps,
where their struct-ness is an optimization, then dissoc should work in
the same way that assoc on an array-map can sometimes return a hash-map.
The main reason I bring this up is that I had no reason to suspect
that the maps returned from my SQL queries were actually struct-maps.
They printed like any other map, and work correctly for every non-
removing map operation. Having some subset of maps error on core API
operations seems opposed to abstraction-oriented programming. It trips
my disgust switch to see code like
(rename-keys
(if (struct-map? m)
(into {} m)
m)
{:foo :bar})
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to [email protected]
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
