Hi,
On Feb 1, 1:57 pm, Timothy Pratley <timothyprat...@gmail.com> wrote:
> Good idea, but peek and pop work differently on vectors and sequences,
> seeing get-in is not constrained to use vectors this could lead to an
> unexpected behavior:
> user=> (def m {:a 1, :b 2, :c {:d 3, :e 4}, :f nil})
> #'user/m
> user=> (get-in3 m '(:c :e) 2) ;peek-pop keys applied in unexpected order
> 2
> user=> (get-in2 m '(:c :e) 2) ;expected result
> 4
o.O Ok... 100% of my use-cases for get-in were with vectors up to now.
Didn't think about the allowing lists also.
> I've replaced the patch on assembla with this:
> (reduce #(get %1 %2 not-found) m ks)))
> And added test cases for the falsey returns and seq args
Consider this (admittedly constructed) case:
(get-in {:a {:b 1}} [:x :c] {:c :uhoh})
I would not mind only allowing vectors in the interface. I would
expect the length of such a chain sufficiently short for easy
conversion if necessary. Or to use butlast/last instead of peek/pop.
Again the "damage" would be limited by the short keychain length.
(Of course it would have to be considered: is the usual keychain
really short?)
Sincerely
Meikel
--
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
