From: Jason Merrill <jason.merrill@...>
Date: 2006-08-29T12:22:30+09:00
Subject: Re: Should Array.new(n, obj) be deprecated?

> From what I've been told, there are performance trade-offs.

Point taken:

bm(12) do |test|
    test.report("firstway:") do
        a1 = Array.new(10000000,0)
    end
    test.report("secondway:") do
        a2 = Array.new(10000000) {0}
    end
end

=>
                               user      system           total             real
firstway:            0.110000    0.020000    0.130000 (   0.130000)
secondway:       6.199000    0.030000    6.229000 (   6.289000)

So there probably is a reason to have a hook to the fast way (that is,
the first way).  I wish it were harder to do it the fast way and
easier to do it the slow way with more obvious behavior, but I
certainly wouldn't want to change the block syntax, since it is nicely
consistent with the language, and I don't know how I would change the
syntax of the fast and confusing way.

Anyways, thanks for helping me understand this design decision.
Status quo it is.  I guess it's pretty likely that I'll make the
newbie mistake again myself, and in fairness, the behavior of the
constructors is pretty clearly documented.


> What wrong with
>
>   [obj] * n

I didn't know that was possible, but it produces the same behavior
that I thought was stange that the first constructor method produces.
Namely:

arr = ['a']*6
arr[0].gsub!(/a/,'b')

Now arr contains six references to the same instance of 'b'.

Cheers,

Jason