The following message is a courtesy copy of an article
that has been posted to comp.lang.misc as well.

Yukihiro Matsumoto <matz / netlab.co.jp> writes:

> |> some classes do not invoke `initialize' in their `new'
> |> method.  They are Array, Regexp, IO (and its subclasses),
> |> Hash, String, Thread, Class, and Module.  
> |> # I'm feeling something left.

,,,

>   * these classes define their own version of `new' rather than using
>     generic `new' defined in Object class.  these `new' methods
>     use argument to allocate object, before calling `initialize' if any.
> 
> The latter is more significant.  The `initialize' trick works well
> only if the arguments are used to initialize, not to allocate object.
> 
> For example, `new' of Array class uses its argument to determine
> allocation size of internal buffer.  Calling `initialize' in the
> method is useless, because meaning of an argument is already fixed.

If we take Array as an example, why can't the internal 'new' method do
the allocation, and then call .initialize with the parameters. Agreed,
there's no allocation that .initialize can do, but it might still be
interested in the arguments anyway.

Say I wanted a subclass of array that stored only uppercase
strings. If .initialize was called, I could write it as:

     class UpperArray < Array
       def initialize(*args)
         if args.length > 1 and String === args[1].type
           each do |v| v.upcase!  end
         end
       end

       def [](*args) ...
       end
     end

This seems pretty natural. Even though the meaning of the argument is
fixed by 'new', we can still use it to add value.

Is the performance overhead significant?


Regards


Dave