I ran into a similar (in my opinion) issue the other day.
I was working a vector and updating a value at a specific index. Ordering
and performance were important, so it seemed like a good default choice.
(-> [1 2 3] (update-in [1] inc))
Then the code changed a bit, I needed to filter some elements out. I ended
up with code similar to what's below
(-> (filter odd? [1 2 3])
(update-in [1] inc))
The above code fails, since my vector becomes a lazyseq.
I solved the issue in a different way, but I was a bit disappointed that
using filter caused me to have to move away from updating at an index.
On Wed, Aug 7, 2013 at 9:45 AM, Jay Fields <j...@jayfields.com> wrote:
> that's kind of my point, you wouldn't use contains? with a list 99.99% of
> the time (you probably want some), so if the perf is terrible while you're
> figuring out that you want some, it doesn't matter.
>
>
> On Wed, Aug 7, 2013 at 9:39 AM, Jeremy Heiler <jeremyhei...@gmail.com>wrote:
>
>> On August 7, 2013 at 9:02:51 AM, Tassilo Horn (t...@gnu.org) wrote:
>>
>> Jay Fields <j...@jayfields.com> writes:
>>
>> > For a list, it seems like converting the list to a vectoc (via vec)
>> > would be a reasonable solution, though I'm sure there's some side
>> > effect that I haven't considered. Perf would be impacted, but this
>> > doesn't seem like the kind of thing you'd want to do anyway, so having
>> > poor perf wouldn't be the end of the world. At least it wouldn't
>> > exception out.
>>
>> IMHO, it would be bad if converting lists (and seqs?) to vectors would
>> be done under the hoods. There are high chances that you accidentally
>> pass a seq/list to `contains?` and then suffer from worse performance
>> without actually noticing. E.g. you do something like
>>
>> (contains? (map fuddle blabla) 3) ;; has at least 4 items
>>
>> where you actually wanted to do
>>
>> (contains? (mapv fuddle blabla) 3) ;; has at least 4 items
>>
>> I'm not sure any conversion should take place. The confusion with vectors
>> is that (contains? [1 2 3 4] 3) returns true because there are four
>> elements, not because 3 is present. So by returning false, false
>> assumptions are being validated in various cases.
>>
>>
>>
>
--
--
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.
