There are still some sharp edges I'm not sure about:
(A) user=> (get-in {:a 1} [])
{:a 1}
;; this is existing behavior, but I feel the result should be nil
+1 for nil
I think I disagree.
If you view 'get-in' as an unwrapping operation, unwrapping by zero
steps should return the existing collection, no?
{:foo {:bar {:baz 1}}}
[] => {:foo ...
[:foo] => {:bar ...
[:foo :bar] => {:baz ...
This maps trivially to a sophisticated user's recursive mental model
of get-in:
(defn get-in [m ks]
(loop [looking-at m
first-key (first ks)
remaining-keys (rest ks)]
(if-not first-key
looking-at
(recur (get looking-at first-key)
(first remaining-keys)
(rest remaining-keys)))))
... if there are no keys, it returns m. That's intuitive to me, at
least.
Can you explain why you think the result should be nil?
(B) user=> (get-in {:a 1} nil)
{:a 1}
;; this is existing behavior, but I feel the result should be nil
(nil
is a seq so not an exception)
+1 for nil
As above: I equate nil with the empty sequence.
--
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
