From: Walton Hoops <walton@...>
Date: 2010-03-16T04:14:33+09:00
Subject: Re: Overriding new?

On 3/15/2010 12:48 PM, Andrea Dallera wrote:
> Hei,
>
> 	I am uncertain about what to do: on one side I'm very aware that it
> would be a huge hack and, before all, using this kind of "template
> method" in the base class, and having every element to inherit from it,
> is very unflexible. On the other side i've been using freightrain for
> quite a while now and i really really like the syntactic sugar, so
> things like
> MyFactory.getInstance() do
>   # user defines their behavior here
> end
> as Walton (which i thank for the pointer) suggested are a big no no.
>
> I like this way of doing it:
> def new(*a,&b)
>   obj = allocate
>   #do your stuff
>   obj.send(:initialize,*a,&b)
>   return obj
> end
>
> What do you think about it? Aside from the performance hit (in my case i really don't case), are there any motivation i'm not seeing for not using it?
> Also forbidding to specify the constructor would be a way to go but i'd like to allow as much freedom as possible.
>
>   
I assume that '#do your stuff' is where you do things like call the
parents initializer?
1) What happens is the programmer *does* call super in initialize. 
While sometimes it's ok for code to get run twice, sometimes it's not. 
Be sure that if you are ensuring the parent class's initialize method
runs, that it doesn't foobar something if it runs twice because the user
called 'super'.
2) Are you sure there isn't an instance where someone would want to
subclass your class, but not run the parents initializer? One example
where I can think of this occurring is doing mocks for unit testing.  I
may still want to use some of the functionality from your class (thus
subclassing it), but cut out some of the backing guts and replace them
with something I have control over.

Provided you have thought about those two things, and still think this
is the right choice, then I see no problem with this code.