Re: SWIG & the New Allocation Framework (Ruby 1.7)

> L> It looks like the implementation of Foo#initialize should remain the
> L> same. Is there more to it than that?
>
>  If you do this all method call must be protected to be sure that
>  #initialize was called. This is what ruby do, for example, with File
>
> pigeon% ruby -e 'a = File.allocate; a.read'
> -e:1:in `read': uninitialized stream (IOError)
>         from -e:1

Of course you're correct, but is it intended that the user will call
Foo.allocate *directly* (as your example shows)? I was under the impression
that code would continue to call Foo.new, which has the following
consequences:

 1. Calling Foo.new results in a call to rb_class_new_instance();
 2. rb_class_new_instance() first calls rb_obj_alloc(), resulting in a call
to Foo.allocate;
 3. rb_class_new_instance() follows this up with a call to
rb_call_obj_init(), resulting in a call to Foo#initialize.

As I said in my original post, I'm not entirely clear on the motivations for
this change and so perhaps it's intended that the user will also call
Foo.allocate from Ruby code. And if so, I agree that they'd better make sure
to initialize the new object before using it!

Thanks,

Lyle