It should, shouldn’t it? It’s meant to combine the fast lookup of
Hash with the convenience of Array, yet the most important method Hash
and Array have in common, Set lacks!
$ irb
irb(main):001:0> require ‘set’
=> true
irb(main):002:0> s = Set[1,2,3]
=> #<Set: {1, 2, 3}>
irb(main):003:0> s.include? 1
=> true
irb(main):004:0> s[1]
NoMethodError: undefined method `[]’ for #<Set: {1, 2, 3}>
from (irb):4
This would be a good thing to fix before 1.8 is released.
Gavin
from :0
What should it return - true/false? In which case it would just be an alias
of ‘include?’ ? Personally I don’t like having lots of aliases for the same
method.
Remember that sets are unordered, and each distinct element can occur only
once. So it’s not much like an Array at all; it’s more like a Hash where the
stored value is always ‘true’
s = Hash.new(false)
s[‘red’] = true
s[‘green’] = true
p s.include?(‘red’) #>> true
p s.include?(‘blue’) #>> false
Regards,
Brian.
On Sun, Jul 27, 2003 at 02:28:06AM +0900, Gavin Sinclair wrote:
It should, shouldn’t it? It’s meant to combine the fast lookup of
Hash with the convenience of Array, yet the most important method Hash
and Array have in common, Set lacks!
Saluton!
It should, shouldn’t it? It’s meant to combine the fast lookup of
Hash with the convenience of Array, yet the most important method Hash
and Array have in common, Set lacks!$ irb
irb(main):001:0> require ‘set’
=> true
irb(main):002:0> s = Set[1,2,3]
=> #<Set: {1, 2, 3}>
irb(main):003:0> s.include? 1
=> true
irb(main):004:0> s[1]
NoMethodError: undefined method `’ for #<Set: {1, 2, 3}>
from (irb):4
from :0
Ruby follows the principle of least surprise. Am I the only one to be
stupefied if ‘’ would exist for a set?
Gis,
Josef ‘Jupp’ Schugt
–
N’attribuez jamais à la malice ce que l’incompétence explique !
– Napoléon
Oh well, judging by the responses, I guess it’s not all that sensible
after all.
I just don’t like typing “include?” for something as simple as a lookup,
especially when Set (to my mind) is just a special case of Hash –
with a bit more thrown in. Also since “include?” is bad grammar.
Another question, then. Why does Set#| return a Set, but Set#&
returns an Array?
Gavin
On Sunday, July 27, 2003, 3:28:06 AM, Gavin wrote:
It should, shouldn’t it? It’s meant to combine the fast lookup of
Hash with the convenience of Array, yet the most important method Hash
and Array have in common, Set lacks!
[…]
I’d love to see a short synonym for Set#include?, but Set# isn’t it.
Subscripting a set just doesn’t make sense to me.
martin
Gavin Sinclair gsinclair@soyabean.com.au wrote:
It should, shouldn’t it? It’s meant to combine the fast lookup of
Hash with the convenience of Array, yet the most important method Hash
and Array have in common, Set lacks!
It could return member or false –
s = Set.new([‘a’, ‘b’])
s[‘a’] → ‘a’
s[‘c’] → false
Ari
On Sat, 2003-07-26 at 11:39, Brian Candler wrote:
On Sun, Jul 27, 2003 at 02:28:06AM +0900, Gavin Sinclair wrote:
It should, shouldn’t it? It’s meant to combine the fast lookup of
Hash with the convenience of Array, yet the most important method Hash
and Array have in common, Set lacks!What should it return - true/false? In which case it would just be an alias
of ‘include?’ ? Personally I don’t like having lots of aliases for the same
method
Definitely not. When I first saw it, it took me a second to even
realize what the heck it
should do.
On Saturday, July 26, 2003, at 3:08 PM, Josef ‘Jupp’ Schugt wrote:
Saluton!
- Gavin Sinclair; 2003-07-26, 20:13 UTC:
It should, shouldn’t it? It’s meant to combine the fast lookup of
Hash with the convenience of Array, yet the most important method Hash
and Array have in common, Set lacks!$ irb
irb(main):001:0> require ‘set’
=> true
irb(main):002:0> s = Set[1,2,3]
=> #<Set: {1, 2, 3}>
irb(main):003:0> s.include? 1
=> true
irb(main):004:0> s[1]
NoMethodError: undefined method `’ for #<Set: {1, 2, 3}>
from (irb):4
from :0Ruby follows the principle of least surprise. Am I the only one to be
stupefied if ‘’ would exist for a set?
for what is worth, I agree with you.
Possibly Set#has?(x) would fit?
il Sun, 27 Jul 2003 11:08:27 +0900, Gavin Sinclair gsinclair@soyabean.com.au ha scritto::
I just don’t like typing “include?” for something as simple as a lookup,
especially when Set (to my mind) is just a special case of Hash –
with a bit more thrown in. Also since “include?” is bad grammar.
How about Set#> and Set#< which would call superset?, subset?, include?
and raise respectively when given a set or an object? Elements are then a
special case of subsets.
martin
Gavin Sinclair gsinclair@soyabean.com.au wrote:
On Sunday, July 27, 2003, 3:28:06 AM, Gavin wrote:
It should, shouldn’t it? It’s meant to combine the fast lookup of
Hash with the convenience of Array, yet the most important method Hash
and Array have in common, Set lacks!
[…]Oh well, judging by the responses, I guess it’s not all that sensible
after all.I just don’t like typing “include?” for something as simple as a lookup,
especially when Set (to my mind) is just a special case of Hash –
with a bit more thrown in. Also since “include?” is bad grammar.
Oh well, judging by the responses, I guess it’s not all that sensible
after all.
It’s really not; you seem to be confusing keys with values. Consider
this:
myArray = [ 'a', 'b', 'c' ]
If you look for myArray[‘a’], you will not find it; you have to use
myArray.include?(‘a’). Sets work exactly the same way as arrays.
It is hashes that are a special case, in that include? looks at
keys rather than values.
I just don’t like typing “include?” for something as simple as a lookup,
especially when Set (to my mind) is just a special case of Hash –
with a bit more thrown in.
It’s not a lookup; it’s a membership test. Sets are not Hashes - they’re
Arrays that don’t allow duplicate values. Hashes can be used to fake Sets
in languages that don’t have them, because Hashes don’t allow duplicate
keys - but that’s incidental to the definition.
Also since “include?” is bad grammar.
First you’re complaining about how much you have to type, and now you
want to add another character just to make it fit English grammar? 
Just think of it as a return to the days when the subjunctive mood was
used more in English.
Another question, then. Why does Set#| return a Set, but Set#&
returns an Array?
That sounds like a bug. I would expect both to return a Set.
-Mark
On Sun, Jul 27, 2003 at 11:08:27AM +0900, Gavin Sinclair wrote:
Aredridel wrote:
On Sat, 2003-07-26 at 11:39, Brian Candler wrote:
On Sun, Jul 27, 2003 at 02:28:06AM +0900, Gavin Sinclair wrote:
It should, shouldn’t it? It’s meant to combine the fast lookup of
Hash with the convenience of Array, yet the most important method Hash
and Array have in common, Set lacks!What should it return - true/false? In which case it would just be an alias
of ‘include?’ ? Personally I don’t like having lots of aliases for the same
methodIt could return member or false –
s = Set.new([‘a’, ‘b’])
s[‘a’] → ‘a’
s[‘c’] → false
What if false is a member of the set?
GS = Gavin Sinclair
MR = me
Another question, then. Why does Set#| return a Set, but Set#&
returns an Array?
That sounds like a bug. I would expect both to return a Set.
And I can’t reproduce it, either; they both seem to return Sets:
$ irb -r set
irb(main):001:0> s = Set.new [1,2,3,4]
=> #<Set: {1, 2, 3, 4}>
irb(main):002:0> t = Set.new [2,4,6,8]
=> #<Set: {6, 2, 8, 4}>
irb(main):003:0> s | t
=> #<Set: {6, 1, 2, 8, 3, 4}>
irb(main):004:0> s & t
=> #<Set: {2, 4}>
irb(main):005:0>
I disagree - Arrays are ordered, Sets are not.
irb(main):003:0> a = Set[1,2,3,4,5]
=> #<Set: {5, 1, 2, 3, 4}>
Regards,
Brian.
On Wed, Jul 30, 2003 at 11:07:02AM +0900, Mark J. Reed wrote:
It’s not a lookup; it’s a membership test. Sets are not Hashes - they’re
Arrays that don’t allow duplicate values.
True, which is why s[n] doesn’t make sense for numerical indices n, either.
I wasn’t being precise; I was just trying to make the point that for
purposes of my argument and the message to which I was replying, sets
are more arraylike than hashlike. They are, of course, actually a
third, completely different animal.
Sets are unordered collections of individual items. There is no
explicit or implicit mapping between these items and any other set
of entities.
Arrays are also collections of individual items, but the items are ordered;
there is therefore an implicit mapping to the items from the set of
nonnegative integers.
Hashes are unordered collections of (key, value) pairs, which therefore
comprise a mapping from the set of keys to the set of values.
-Mark
On Wed, Jul 30, 2003 at 04:23:27PM +0900, Brian Candler wrote:
On Wed, Jul 30, 2003 at 11:07:02AM +0900, Mark J. Reed wrote:
It’s not a lookup; it’s a membership test. Sets are not Hashes - they’re
Arrays that don’t allow duplicate values.I disagree - Arrays are ordered, Sets are not.
It’s not a lookup; it’s a membership test. Sets are not Hashes - they’re
Arrays that don’t allow duplicate values.I disagree - Arrays are ordered, Sets are not.
True, which is why s[n] doesn’t make sense for numerical indices n, either.
I wasn’t being precise; I was just trying to make the point that for
purposes of my argument and the message to which I was replying, sets
are more arraylike than hashlike. They are, of course, actually a
third, completely different animal.
I agree, of course, so the comment below is to be taken as another
description, instead of literal definition.
Sets are unordered collections of individual items. There is no
explicit or implicit mapping between these items and any other set
of entities.
Arrays are also collections of individual items, but the items are ordered;
there is therefore an implicit mapping to the items from the set of
nonnegative integers.
Hashes are unordered collections of (key, value) pairs, which therefore
comprise a mapping from the set of keys to the set of values.
Sets could also be considered a mapping from all objects to true or false.
Those objects which map to true are “in” the set. Those which map to
false are not. This implies non-duplication and unorderedness.
My point is that I don’t care about data type definitions that
forcefully distinguish between keys and values.
Gavin
On Thursday, July 31, 2003, 2:11:47 AM, Mark wrote:
On Wed, Jul 30, 2003 at 04:23:27PM +0900, Brian Candler wrote:
On Wed, Jul 30, 2003 at 11:07:02AM +0900, Mark J. Reed wrote: