Re^2: Rename a Moo constructor from "new" to "run"

I agree with that! The OP's whole question just seems odd to me.

If there is no public I/F to an object, then what's the point of the object? If it is created by new() or run() or whatever and then very next line is the Perl version of "destroy", that code would warrant a #comment to explain that weirdness regardless of how the object was created in the first place - any new() vs run() would be explained also in that #comment. If this object is that simple, why need Moo in the first place? In traditional Perl OO, you can name the new() function whatever you want. Trying to make Moo do something that it doesn't want to do (like replace new() with run()) sounds like a bad idea. I would think either let Moo do it or do it yourself. I haven't used Moo in production, but I guess the idea is to automate and make easier the mechanics of object creation - why override that? If no object is needed in the first place, why have one?

Comment on Re^2: Rename a Moo constructor from "new" to "run"

Replies are listed 'Best First'.
Re^3: Rename a Moo constructor from "new" to "run" by Corion (Patriarch) on Mar 28, 2019 at 08:09 UTC
Maybe you want to have different implementations or want to replace some parts, while still having a defined sequence of calls. Personally, I've always run up to the limits of such frameworks, but I can well imagine an ETL task that is basically: `package ETL::Import; sub run( $class, $input_file, $table ) { my $payload = $class->convert_to_csv( $input_file ); $class->cleanup( $payload ); $class->load( $payload, $input_file, $table ); $class->verify( $payload, $table ); };` [download] ... and then having `package ETL::Import::CSV; ... package ETL::Import::Fixed; ...` [download] ... where each class only overrides (say) `->convert_to_csv` and/or `->cleanup`. As I said, I've almost always wanted to change just a tiny bit in the sequence of the call order, or maintain just one bit more information, so I prefer to have the logic of `->run` in the main program instead of having it in some superclass. But if `->run` is the result of a refactoring where it has proven flexible enough already, I can see how that could work out.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^3: Rename a Moo constructor from "new" to "run"
by Corion (Patriarch) on Mar 28, 2019 at 08:09 UTC

Maybe you want to have different implementations or want to replace some parts, while still having a defined sequence of calls.

Personally, I've always run up to the limits of such frameworks, but I can well imagine an ETL task that is basically:


package ETL::Import;

sub run( $class, $input_file, $table ) {
    my $payload = $class->convert_to_csv( $input_file );
    $class->cleanup( $payload );
    $class->load( $payload, $input_file, $table );
    $class->verify( $payload, $table );
};
[download]

... and then having

package ETL::Import::CSV;

...

package ETL::Import::Fixed;

...
[download]

... where each class only overrides (say) ->convert_to_csv and/or ->cleanup.

As I said, I've almost always wanted to change just a tiny bit in the sequence of the call order, or maintain just one bit more information, so I prefer to have the logic of ->run in the main program instead of having it in some superclass. But if ->run is the result of a refactoring where it has proven flexible enough already, I can see how that could work out.

[reply]
[d/l]
[select]