Alternatives to contains?
I know this has been discussed on the list before to some extent, but does clojure by default have any operations which actually do what "contains?" sounds like it would do, for all collections? I know that you can easily write something similar using "some", but often times you just want to find if something is in a list of items. I've seen Rich say that contains? is for associative things, but I think it is an unfortunate name - if the idea is to express that the collection has a value for that key, I think the name would ideally express that, like: contains-key? has-key? maps? I see that clojure-contrib has includes?, which perhaps indicates that clojure by default doesn't have such a function. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Alternatives to contains?
On Thu, Jan 29, 2009 at 1:06 PM, Paul Mooser wrote: > > I know this has been discussed on the list before to some extent, but > does clojure by default have any operations which actually do what > "contains?" sounds like it would do, for all collections? I know that > you can easily write something similar using "some", but often times > you just want to find if something is in a list of items. > > I've seen Rich say that contains? is for associative things, but I > think it is an unfortunate name - if the idea is to express that the > collection has a value for that key, I think the name would ideally > express that, like: > > contains-key? > has-key? > maps? > I would prefer has-key? for checking if a key is in a map and contains? for checking if an element is in a collection. -- Cosmin Stejerean http://offbytwo.com --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Alternatives to contains?
On Jan 29, 2009, at 2:55 PM, Cosmin Stejerean wrote: > > > On Thu, Jan 29, 2009 at 1:06 PM, Paul Mooser > wrote: > > I know this has been discussed on the list before to some extent, but > does clojure by default have any operations which actually do what > "contains?" sounds like it would do, for all collections? I know that > you can easily write something similar using "some", but often times > you just want to find if something is in a list of items. > > I've seen Rich say that contains? is for associative things, but I > think it is an unfortunate name - if the idea is to express that the > collection has a value for that key, I think the name would ideally > express that, like: > > contains-key? > has-key? > maps? > > I would prefer has-key? for checking if a key is in a map and > contains? for checking if an element is in a collection. What about leaving "contains?" as is and adding "in?" which would work like "in" in python. (contains? [1 2 50] 50) => false (in? [1 2 50] 50) => true --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Alternatives to contains?
On Thu, Jan 29, 2009 at 3:56 PM, Dan Larkin wrote: > > On Jan 29, 2009, at 2:55 PM, Cosmin Stejerean wrote: > > > > On Thu, Jan 29, 2009 at 1:06 PM, Paul Mooser wrote: > >> >> I know this has been discussed on the list before to some extent, but >> does clojure by default have any operations which actually do what >> "contains?" sounds like it would do, for all collections? I know that >> you can easily write something similar using "some", but often times >> you just want to find if something is in a list of items. >> >> I've seen Rich say that contains? is for associative things, but I >> think it is an unfortunate name - if the idea is to express that the >> collection has a value for that key, I think the name would ideally >> express that, like: >> >> contains-key? >> has-key? >> maps? >> > > I would prefer has-key? for checking if a key is in a map and contains? for > checking if an element is in a collection. > > > What about leaving "contains?" as is and adding "in?" which would work like > "in" in python. > > (contains? [1 2 50] 50) => false > (in? [1 2 50] 50) => true > > If in? was to be added how would it behave when given a map as the first argument? I would rather have "contains?" do the right thing for list/vectors/sets and keep its current behavior for maps. If we do actually need a function like contains that ONLY accepts a map as the first argument I think a name like has-key? is the most intuitive. -- Cosmin Stejerean http://offbytwo.com --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Alternatives to contains?
On Jan 29, 2009, at 5:23 PM, Cosmin Stejerean wrote:
>
> If in? was to be added how would it behave when given a map as the
> first argument? I would rather have "contains?" do the right thing
> for list/vectors/sets and keep its current behavior for maps. If we
> do actually need a function like contains that ONLY accepts a map as
> the first argument I think a name like has-key? is the most intuitive.
>
I think "in?" would behave like "contains?" when given a map:
(in? {:a 1 :b 2 :c 3} :a) => true
(in? {:a 1 :b 2 :c 3} :d) => false
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Alternatives to contains?
On Thu, Jan 29, 2009 at 5:32 PM, Dan Larkin wrote:
>
> On Jan 29, 2009, at 5:23 PM, Cosmin Stejerean wrote:
>>
>> If in? was to be added how would it behave when given a map as the
>> first argument? I would rather have "contains?" do the right thing
>> for list/vectors/sets and keep its current behavior for maps. If we
>> do actually need a function like contains that ONLY accepts a map as
>> the first argument I think a name like has-key? is the most intuitive.
>
> I think "in?" would behave like "contains?" when given a map:
>
> (in? {:a 1 :b 2 :c 3} :a) => true
> (in? {:a 1 :b 2 :c 3} :d) => false
I thought we had beaten this one entirely to death:
http://groups.google.com/group/clojure/browse_thread/thread/ff224d2b88b671e7/575cefc2c03ce154
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
-~--~~~~--~~--~--~---
Re: Alternatives to contains?
On Thu, Jan 29, 2009 at 4:48 PM, Chouser wrote:
>
> On Thu, Jan 29, 2009 at 5:32 PM, Dan Larkin wrote:
>>
>> On Jan 29, 2009, at 5:23 PM, Cosmin Stejerean wrote:
>>>
>>> If in? was to be added how would it behave when given a map as the
>>> first argument? I would rather have "contains?" do the right thing
>>> for list/vectors/sets and keep its current behavior for maps. If we
>>> do actually need a function like contains that ONLY accepts a map as
>>> the first argument I think a name like has-key? is the most intuitive.
>>
>> I think "in?" would behave like "contains?" when given a map:
>>
>> (in? {:a 1 :b 2 :c 3} :a) => true
>> (in? {:a 1 :b 2 :c 3} :d) => false
>
> I thought we had beaten this one entirely to death:
> http://groups.google.com/group/clojure/browse_thread/thread/ff224d2b88b671e7/575cefc2c03ce154
>
> 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?
I vote for too verbose. ;-)
> And if you really don't want to use it (why again?) there is
> clojure.contrib.seq-utils/includes?, so why not use that?
I'd like for that to be moved to core so I don't have to load it ...
which is also verbose for something that is commonly needed.
--
R. Mark Volkmann
Object Computing, Inc.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Alternatives to contains?
On Thu, Jan 29, 2009 at 2:52 PM, Mark Volkmann
wrote:
>> 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?
>
> I vote for too verbose. ;-)
(some #{:y] [:x :y :z]) is fewer characters than
(includes? :y [:x :y :z]) so your vote of "too verbose" is hard to justify.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Alternatives to contains?
On Thu, Jan 29, 2009 at 5:03 PM, Mark Engelberg
wrote:
>
> On Thu, Jan 29, 2009 at 2:52 PM, Mark Volkmann
> wrote:
>>> 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?
>>
>> I vote for too verbose. ;-)
>
> (some #{:y] [:x :y :z]) is fewer characters than
> (includes? :y [:x :y :z]) so your vote of "too verbose" is hard to justify.
Good point. I was thinking more in terms of number of "noise"
characters instead of number of total characters. Looking at it that
way it's
(${}[])
versus
([])
The current form requires you to think a little more. You're thinking
"I want to see if this thing is one of several possible values.
So I want to compare one thing to a set of things.
How do I do that?
Oh, I have to put the one thing in a set and the set of things in a vector."
That's easy to remember if you code in Clojure daily, but not so easy
if you only code in Clojure once every two weeks and code in Java or
something else the rest of the time.
--
R. Mark Volkmann
Object Computing, Inc.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Alternatives to contains?
Well, sorry for bringing it up again, but the reason I did so is that
uncommonly confusing because of the name, 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 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
-~--~~~~--~~--~--~---
Re: Alternatives to contains?
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 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
-~--~~~~--~~--~--~---
Re: Alternatives to contains?
Hi! Am 29.01.2009 um 23:52 schrieb Mark Volkmann: > I'd like for that to be moved to core so I don't have to load it ... > which is also verbose for something that is commonly needed. "includes?" being commonly needed might indicate that people really should be using sets instead of lists or vectors in these cases. Sets are the only data structures that provide efficient contains?(-value), plus contains? works as expected with sets. My guess is that the omission of includes? in core is not an oversight after all, but an incentive to pick the right data structure for the task at hand. Kind regards, achim --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Alternatives to contains?
Additionally, I initially found (some #{:y} [:x :y :z]) to be
confusing. The documentation of "some" (and or, in turn) uses the
phrase "logical true" - I initially assumed this to mean actually
true, but I suppose what it means is "not false or nil".
In that case, it makes me think of the degenerate example (I realize
this is slightly stupid):
(some #{false} (list false))
On Jan 29, 2:48 pm, Chouser wrote:
> 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?
> --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
-~--~~~~--~~--~--~---
Re: Alternatives to contains?
I understand that sets or hash maps are more efficient structures for lookups. However, in certain cases (especially if I'm programming something interactively), I have either short lists or data which is naturally a list that will be faster to walk through than to convert it to a set (which implicitly assumes I'll walk through it). Anyway, point taken, but I'm not sure that completely addresses the question I'm posing. On Jan 29, 3:23 pm, Achim Passen wrote: > My guess is that the omission of includes? in core is not an oversight > after all, but an incentive to pick the right data structure for the > task at hand. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Alternatives to contains?
> In that case, it makes me think of the degenerate example (I realize
> this is slightly stupid):
>
> (some #{false} (list false))
Maybe this is an argument for adding "any?" to the list of core
functions?
-Jason
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Alternatives to contains?
actually rhickey showed up on irc and pointed something out:
15:23 rhickey : user=> (.contains [1 2 3] 2)
15:23 rhickey : true
15:23 rhickey : user=> (.contains '(1 2 3) 2)
15:23 rhickey : true
15:23 rhickey : what contains debate? :)
so because seqs, vectors, etc are java collections
user=> (.contains (map #(.getName %) (.getMethods (class (seq [:a]
"contains")
true
http://java.sun.com/j2se/1.4.2/docs/api/java/util/Collection.html
On Thu, Jan 29, 2009 at 3:38 PM, Jason Wolfe wrote:
>
> > In that case, it makes me think of the degenerate example (I realize
> > this is slightly stupid):
> >
> > (some #{false} (list false))
>
> Maybe this is an argument for adding "any?" to the list of core
> functions?
>
> -Jason
> >
>
--
And what is good, Phaedrus,
And what is not good—
Need we ask anyone to tell us these things?
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Alternatives to contains?
except (.contains nil 2) ==> NPE
:-)
-Jason
On Jan 29, 2009, at 3:55 PM, Kevin Downey wrote:
> actually rhickey showed up on irc and pointed something out:
>
> 15:23 rhickey : user=> (.contains [1 2 3] 2)
> 15:23 rhickey : true
> 15:23 rhickey : user=> (.contains '(1 2 3) 2)
> 15:23 rhickey : true
> 15:23 rhickey : what contains debate? :)
>
>
> so because seqs, vectors, etc are java collections
>
> user=> (.contains (map #(.getName %) (.getMethods (class (seq
> [:a] "contains")
> true
>
> http://java.sun.com/j2se/1.4.2/docs/api/java/util/Collection.html
>
> On Thu, Jan 29, 2009 at 3:38 PM, Jason Wolfe
> wrote:
>
> > In that case, it makes me think of the degenerate example (I realize
> > this is slightly stupid):
> >
> > (some #{false} (list false))
>
> Maybe this is an argument for adding "any?" to the list of core
> functions?
>
> -Jason
>
>
>
>
> --
> And what is good, Phaedrus,
> And what is not good—
> Need we ask anyone to tell us these things?
>
> >
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Alternatives to contains?
Good point - I actually looked in Collections, but failed to look in Collection itself. On Jan 29, 3:55 pm, Kevin Downey wrote: > actually rhickey showed up on irc and pointed something out: > ... --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Alternatives to contains?
On Jan 29, 5:48 pm, Chouser wrote:
> What is the drawback of the (some #{:y} [:x :y :z]) idiom?
Too hard to understand at first, which is why I wrote seq-utils/
includes?.
But a note to all: I've hardly used includes? since I wrote it. I
found that if I was testing for the presence/absence of elements in a
collection, then I was usually better off using a set in the first
place.
Most languages don't include sets as standard types, so we don't think
of them. But whenever you have a collection in which order doesn't
matter, a set is often better than a vector or list.
-Stuart Sierra
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Alternatives to contains?
This is actually the point of this whole debate. You would assume that
contains? works like java.util.Collection.contains, but instead it means
something completely semantically different.
user=> (.contains [4 5 6] 4)
true
user=> (contains? [4 5 6] 4)
false
Even worse, you do this and think it works:
user=> (.contains [1 2 3] 1)
true
user=> (contains? [1 2 3] 1)
true
This isn't about having a method that does the same thing as .contains or
includes? from contrib, it's about naming this method, the one that tells
you if the associative thing has a particular key, something less confusing.
This is just one of those things that a lot of people new to Clojure will
learn the hard way at some point. And they'll probably send another email
to the mailing list and we'll have the debate all over again. Once Clojure
goes 1.0, this problem is permanent, so we have until then to convince Rich
to rename this method to contains-key? (which mimics the name in the
java.util.Map interface) or has-key? (for something shorter).
Maybe I'll setup http://pleaserenamecontainsrich.com :)
On Thu, Jan 29, 2009 at 6:55 PM, Kevin Downey wrote:
> actually rhickey showed up on irc and pointed something out:
>
> 15:23 rhickey : user=> (.contains [1 2 3] 2)
> 15:23 rhickey : true
> 15:23 rhickey : user=> (.contains '(1 2 3) 2)
> 15:23 rhickey : true
> 15:23 rhickey : what contains debate? :)
>
>
> so because seqs, vectors, etc are java collections
>
> user=> (.contains (map #(.getName %) (.getMethods (class (seq [:a]
> "contains")
> true
>
> http://java.sun.com/j2se/1.4.2/docs/api/java/util/Collection.html
>
> On Thu, Jan 29, 2009 at 3:38 PM, Jason Wolfe wrote:
>
>>
>> > In that case, it makes me think of the degenerate example (I realize
>> > this is slightly stupid):
>> >
>> > (some #{false} (list false))
>>
>> Maybe this is an argument for adding "any?" to the list of core
>> functions?
>>
>> -Jason
>>
>>
>
>
> --
> And what is good, Phaedrus,
> And what is not good—
> Need we ask anyone to tell us these things?
>
>
> >
>
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Alternatives to contains?
On Jan 29, 10:41 pm, Paul Barry wrote: > This is actually the point of this whole debate. You would assume that > contains? works like java.util.Collection.contains, but instead it means > something completely semantically different. > user=> (.contains [4 5 6] 4) > true > user=> (contains? [4 5 6] 4) > false > > Even worse, you do this and think it works: > > user=> (.contains [1 2 3] 1) > true > user=> (contains? [1 2 3] 1) > true > > This isn't about having a method that does the same thing as .contains or > includes? from contrib, it's about naming this method, the one that tells > you if the associative thing has a particular key, something less confusing. > > This is just one of those things that a lot of people new to Clojure will > learn the hard way at some point. And they'll probably send another email > to the mailing list and we'll have the debate all over again. Once Clojure > goes 1.0, this problem is permanent, so we have until then to convince Rich > to rename this method to contains-key? (which mimics the name in the > java.util.Map interface) or has-key? (for something shorter). > > Maybe I'll setuphttp://pleaserenamecontainsrich.com:) > Sequential lookup is not an important operation. Clojure includes sets and maps, and if you are going to be looking things up you should be using them. contains? maps to java.util.Set.contains. The fact that java.util.Collection also has contains is, IMO, a mistake, as you really can't write code to an interface with dramatically varying performance characteristics. So, lookups in sets and maps take priority and get the best name - contains? People write naive programs that do linear lookups with contains() in other languages, and get correspondingly bad n-squared performance - that's not an argument for encouraging that in Clojure. If they get an explanation of why it's a bad idea, and how to use sets and maps, that's fine. If you want a linear lookup function, it's going to have a big warning- sign name, like linear-lookup. I'm not persuaded in any way to rename contains? Rich --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Alternatives to contains?
On Thu, Jan 29, 2009 at 5:23 PM, Achim Passen wrote:
> Hi!
> Am 29.01.2009 um 23:52 schrieb Mark Volkmann:
>
> I'd like for that to be moved to core so I don't have to load it ...
> which is also verbose for something that is commonly needed.
>
> "includes?" being commonly needed might indicate that people really should
> be using sets instead of lists or vectors in these cases. Sets are the only
> data structures that provide efficient contains?(-value), plus contains?
> works as expected with sets.
> My guess is that the omission of includes? in core is not an oversight after
> all, but an incentive to pick the right data structure for the task at hand.
Embarassingly, I hadn't even considered that option. I'm happy with
the following.
user=> (def s #{"a" "c" "d" "m"})
#'user/s
user=> (contains? s "d")
true
user=> (contains? s "e")
false
You're right. I was using a vector where I should have used a set.
--
R. Mark Volkmann
Object Computing, Inc.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
