in reply to Re^5: Override new in Moose for flyweight objects
in thread Override new in Moose for flyweight objects

I think we're getting far afield of the original topic, but that's okay, this is way more interesting than Stackoverflow's format :)

I've been more or less forced into the C# world these last couple of years, where dependency injection isn't just a technique, but a way of life. And I've been less than impressed by the alleged improvements this is supposed to make when done the C# way. For the most part, I've managed to reject it. There are places where it's useful, but I've yet to be convinced on many other places. And there are places where it's downright harmful. But I digress.

Now, I'm assuming your hardcoded $testing would normally be done via some other method, whether environment variable or some other global variable, it's just here this way for example. With that, you just wrapped around MyApp::new_widget so that you could change its behaviour. I'm curious, though, why you couldn't just wrap around MyApp::Widget::new instead. Which, truth be told, is pretty much what I have done in the past. And once even in production (not test) code. Without Moose or any other similar framework (again, didn't exist). When done in production, it's called monkey patching. When done in test, it's called mocking :)

Now, I'm not arguing that you should change all your code, I'm just not convinced that there's really any benefit to bucking convention. If you're creating a Foo, then it should be Foo->new. If that's a traditional factory underneath, doesn't really matter, practically speaking, as it was always a factory anyway. And if a particular constructor needs to temporarily be replaced with a different one, well, you can always replace it, even just temporarily. (Hey, if you can hawk your modules, so can I :-D )