Well, sorry for bringing it up again, but the reason I did so is I
find the name uncommonly confusing, especially considering how good
the names in clojure are in general. I know not everything can be
clear without reading the documentation, but it was only clear to me
that contains? was not what I wanted because the docs explicitly
stated that it would never search linearly for a value.
I have no problem with higher order functions (obviously), but to me a
recurring theme in functional programming is separating structural
concerns from the code itself. I think it's such a common task to want
to know if a collection contains something that it is very sensible to
provide a function which perform that task for every collection - when
something happens all the time, in almost any program of significant
size, it is often worth giving that something a name.
I realize that Rich has concerns (from reading previous threads on
this subject) about having functions which have widely varying
performance (from constant to linear time) depending on the sort of
collection, but to me it seems very natural to have the performance of
a lookup operation depend on the kind of collection you're looking in.
I would not expect any method that operated on lists to have anything
but linear time, and similarly I'd expect hash table lookups to
provide operations in constant time (or "constant time", with
clojure's maps).
Obviously code like (some #{x} coll) works, but creating a set to use
as a way to search a list to find if it contains an item doesn't
scream "clear" to me - I suppose idioms aren't always chosen for
clarity of expression, or perhaps I'm merely not one of the
initiated, yet.
On Jan 29, 2:48 pm, Chouser <chou...@gmail.com> wrote:
> I thought we had beaten this one entirely to
> death:http://groups.google.com/group/clojure/browse_thread/thread/ff224d2b8...
>
> And yet it lives!
>
> What is the drawback of the (some #{:y} [:x :y :z]) idiom? Is it too
> verbose? Too slow? Too flexible? Too good a re-use of existing
> functionality? Too helpful in opening ones eyes to the possibilities
> of sets and higher order functions?
>
> And if you really don't want to use it (why again?) there is
> clojure.contrib.seq-utils/includes?, so why not use that?
>
> --Chouser
--~--~---------~--~----~------------~-------~--~----~
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
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
-~----------~----~----~----~------~----~------~--~---
