I should have been clearer in the example. This is the actual situation:
and this is what it will become if i apply that solution:
def new(*args, &block)
obj = allocate
obj.send(:initialize, *args, &block)
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
Calling super shouldn’t be a problem in this case: the constructor of
the base class does nothing…right?
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.
Good point. I’m taking care of this, in a way that provides a full stub
(with all the dependencies stubbed and injected) for integration testing
with one line of code, which was one of the initial objectives: i come
from WPF and it can be a pain to write integration testing for a VM with
even just 3 services, i wanted to be able to test without having to
write huge and complex setups all the time. Still, one can think of
other cases where a VM is is still needed “uninitialized”: i guess i’ll
provide an hard switch if the case actually arises.
Thanks a lot for all the suggestions!