On 3/15/2010 2:46 PM, Andrea Dallera wrote: > I should have been clearer in the example. This is the actual situation: > > class FreightViewModel > > def initialize > do_some_init_stuff() > end > > end > > and this is what it will become if i apply that solution: > > class FreightViewModel > > def new(*args, &block) > obj = allocate > obj.do_some_init_stuff > obj.send(:initialize, *args, &block) > return obj > end > > end > > >> 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'. >> > Calling super shouldn't be a problem in this case: the constructor of the base class does nothing...right? > Right, so not an issue in this case. >> 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! > Sounds to me like you've given it plenty of thought and are good to go. Best of luck with your project!