Set doesn't have [] instance method

[Gavin Sinclair]

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


This would be a good thing to fix before 1.8 is released.

Gavin

 

[Aredridel]

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

It could return member or false --

s = Set.new(['a', 'b'])
s['a'] -> 'a'
s['c'] -> false

Ari

 

[David Fayram]

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 :0

Ruby follows the principle of least surprise. Am I the only one to be
stupefied if '[]' would exist for a set?

Definitely not. When I first saw it, it took me a second to even
realize what the heck it
should do.

- Dave "paradox" Fayram
Developer / Idealist

 

[Gavin Sinclair]

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.

Another question, then. Why does Set#| return a Set, but Set#&
returns an Array?

Gavin

 

[gabriele renzi]

il Sun, 27 Jul 2003 11:08:27 +0900, Gavin Sinclair

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.

for what is worth, I agree with you.
Possibly Set#has?(x) would fit?

 

[Martin DeMello]

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.

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

 

[Mark J. Reed]

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

 

[Mark J. Reed]

GS = Gavin Sinclair
MR = me

GS> Another question, then. Why does Set#| return a Set, but Set#&
GS> returns an Array?

MR> 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>

 

[Mark J. Reed]

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.

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

 

[Gavin Sinclair]

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