On Sun, Dec 4, 2011 at 1:05 PM, Eero Saynatkari <ruby-ml / kittensoft.org>wrote:

> On 2011-12-04, at 16:15:00, Alexey Muranov wrote:
> >
> > But what is wrong with having one class instead of two, if internally
> they behave mostly the same, and one literal notation instead of two?
> Anyway, this was just an idea.
>
> Hash tables aren't Sets, nor the other way around. I'd like to avoid
> messing up data structure definitions any more than they already are.
>
> The only compelling reason for bringing Set into core would be a literal
> syntax  and I agree, as a data structure it would be a useful addition and
> encourage its usage  but I don't really have anything to contribute to the
> particular bikeshed of syntax thereof.
>

Actually, the bulk of Set's functionality is already built on top of Hash.
Personally, since the ability to create Hashes from comma-delimited
key,value lists has been removed in 1.9, I think reintroducing it to create
Set literals is not the worst idea in the world.

Additionally, implementing Set functionality directly on top of Hash would
remove the unfortunate method call overhead that currently exists in the
Set library (note that the implementation of Set#include? is just a call
through to Hash#include?):

>> Benchmark.bmbm do |x|
?>   h = {}
>>   s = Set.new
>>   10000.times { |i| h[i] = nil; s << i }
>>   x.report("Hash#include?") { 1000000.times { h.include? rand(20000) } }
>>   x.report("Set#include?") { 1000000.times { s.include? rand(20000) } }
>> end
Rehearsal -------------------------------------------------
Hash#include?   0.370000   0.000000   0.370000 (  0.370516)
Set#include?    0.440000   0.000000   0.440000 (  0.436806)
---------------------------------------- total: 0.810000sec

                    user     system      total        real
Hash#include?   0.370000   0.000000   0.370000 (  0.361795)
Set#include?    0.430000   0.000000   0.430000 (  0.426560)