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

I don't measure hard by keystrokes. That's not irrelevant, but there are more important things than keystrokes. Don't take this the wrong way, I'm not advocating Cobol or Java here, but there are much bigger deals than keystrokes.

Now, I also realise you're probably just playing with a bit of sarcasm, so I just want to point out where traditional new wins out. Maintainability. Every perl programmer expects to create new objects through new. That's why we have that convention - we stole it from other languages. It made things really easy. There was nothing inherent in perl that says it must be new, we just do it by convention. And, as I said before, it's not even technically correct, it's only loosely analogous, since perl's constructors, whether called new or something else, are more factory like (since it's actually bless doing the work, technically, not new, and we actually call that in our constructors, unlike every other language where the object reference is created for you prior to the constructor being called, which makes this much more like an object factory in other languages). However, regardless of the mechanics, it's still the convention.

This means that the learning curve to other objects that also use new as their factory is that much less. It means that code that just calls new and expects an object back Just Works. Following convention means it's easier for everyone.

That you do something weird under the covers inside your own "private" classes, types that aren't intended to be instantiated directly, but through other factories that are more traditional in their factoriness (yes, that is now a word), doesn't matter quite so much. Though even there, I would still encourage following convention as much as possible for the guy who gets to follow you in maintaining that package (having inherited a couple of modules over time, I always appreciate when there is little to learn about its innards because most of it matches general perl convention).

And, in your specific example, which I also understand is a very tiny bit of a significant ecosystem providing some DSL to provide a lot of functionality, I would point out, what does that keystroke save? Because I'm gonna have to look it up each time to know which non-standard constructor to use. The problem here, at least from my perspective, is unnecessary mental load. And by unnecessary, I mean that it doesn't seem to provide any benefit over the standard convention, which makes it more to remember, even if convention is that one extra keystroke longer. I already have to remember all the new ways of doing things in the rest of your ecosystem, but those, at least at first glance, look to provide functionality and thus value - bringing down a lot of boilerplate that I might otherwise skip and thus not check things that I can use your system to handle for little cost. So learning and remembering that stuff seems to be likely to be a worthwhile addition to my knowledgebase. (I'm assuming - I haven't looked that closely, and so I am only going on the quality of code I've seen from you in the past. I don't know you for generally writing Acme-style or -quality code.) But that new constructor style... well, perl definitely allows it. I'm just not seeing the benefit.

But maybe that's just me. Most of my professional life has been more about maintenance than writing new code, and so that's just what I see.

Replies are listed 'Best First'.
Re^5: Override new in Moose for flyweight objects
by tobyink (Canon) on Apr 09, 2020 at 17:07 UTC

    The main motivation is not to save one keystroke (that just ends up happening because "_" is one keystroke fewer than "::"). The main motivation is dependency injection. When you do MyApp::Widget->new() you are hard-coding the class name. Hard-coding is code smell. There are many Perl programmers who would agree that hard-coding is bad, but don't even think of using class names like that as hard-coding. But it is hard-coding and it makes your code less adaptable. The idea in Zydeco is instead of doing MyApp::Widget->new(), you do $self->FACTORY->new_widget(). Now the widget class isn't hard-coded, and if you need to use a different widget class (such as a mock widget for your test suite) you can just wrap new_widget.

    package MyApp { use Zydeco declare => [qw(TestingRole)]; my $testing = true; role TestingRole { ...; } class Widget { ...; } if ($testing) { around new_widget (@args) { my $widget = $self->$next(@args); Moo::Role->apply_roles_to_object($widget, TestingRole->role); return $widget; } } } my $factory = 'MyApp'; print $factory->new_widget, "\n";

    (Note that the declare bit it only so we can declare TestingRole as a bareword for use later on. In general you don't need to declare the existence of roles and classes beforehand.)

      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 )