Dave Thomas <Dave / Thomases.com> writes:

|Yukihiro Matsumoto <matz / netlab.co.jp> writes:
|
|> If allocation at `new' uses its arguments, the argument behavior is
|> fixed, size of internal buffer in this case.  If you want to make
|> subclass of Array, and initialize it by some arguments, you'll meet
|> restriction about arguments to `new'.
|
|But say I was implementing a sortable array, where I wanted to
|allocate twice the requested storage: the first half to hold the
|values, the second half pointers to these values. (Don't ask me why,
|because I have no idea. It's a silly example).
|
|     class MyArray < Array
|       def MyArray.new(size)
|         super(size*2)
|       end
|
|       def initialize(size)
|         self.[size/2...size] = (0...size/2).to_a
|       end
|     end
|
|Now, I know I could do this using delegation, but in this case
|subclassing seems natural. 
|
|If I hadn't read this thread, I'd expect that MyArray.new(3) would
|call MyArray.initialize(6).

Yes, but you have to stick with size.

For example, if you want to create initialized SortedArray
by specifying elements like

  ary = SortedArray(1,5,4,3,7,3)

you just can't.  I feel this as restriction.

In addition, 

|     class PrimeArray < Array
|       def initialize
|         for i in 0...size
|           self.[i] = nextPrime
|         end
|       end
|     end

initialize should always take one argument, even if it does not use
it.  It can be error prone.

|It seems to me that logically, 'new' allocates the storage for the
|object, and 'initialize' initializes that store.

Yes.  The point is the argument to `new' is shared by both methods.  
I think they should belong to `initialize' as much as possible, to
enhance future extensibility.

							matz.
p.s.
I'm getting tired of cross-posting to the list and comp.lang.misc.