From: Dave Thomas <dave@...>
Date: 2008-12-20T08:13:26+09:00
Subject: [ruby-core:20710] Re: [Feature #905] Add String.new(fixnum) to preallocate large buffer


On Dec 19, 2008, at 4:28 PM, Charles Oliver Nutter wrote:

>>
>> String.buffer is not a meaningful name for a constructor, in my  
>> opinion, whereas String.new has a pedigree. By adding a  
>> initial_size: n optional argument, you exactly express the meaning� 
>> you're asking for an initial allocation when String.new executes.  
>> Similarly,
>> Array.new([1,2,3], initial_size: 100)
>
> But Array.new(initial_size: 100).size would == 0. That's  
> confusing...I think buffer better expresses that it's the backing  
> store being sized than the outward expression of the String or Array  
> itself, which is what initial_size means.
>
> I would also expect that the cost of allocating and populating an  
> arguments hash for this would negate some of the gain from adding  
> the new form. Array.buffer(100) adds almost no overhead on top of  
> the physical creation of the backing store and object to wrap it,  
> where Array.buffer(initial_size: 100) creates both a new Array and a  
> new Hash. An implementation detail, sure, but we I think we just  
> need something simple here. Perhaps buffer just doesn't express it  
> clearly enough?

I don't think the cost of a hash is going to be significant--if it is,  
then I'd hope that implementors find a way of optimizing these styles  
of keyword hashes, because they're used more and more  
(*cough*Rails*cough*).

I agree initial_size: is misleading. Perhaps String.new(preallocate: n)


Dave