Most of what Moo faciliates is in the constructor, and most of the tooling of Moo is for creating fancy helpers for constructors.

From my own practice, I can't confirm this (and I also heavily disagree with Tadeusz on the topic). When working with my old Moo(se) code, I find it very helpful that the modules have a clear optical distinction between the dumb data (the has () stuff) and the object methods which actually do things (the sub foo { ...; } things). Maintaining that distinction without Moo(se) needs more discipline than I usually have during my hacking nights.

There is some truth in this if the objects are mainly just dumb data containers which don't have methods beyond the accessors. Not having to write code for these is a nice benefit, but you may put this into the category "fancy helpers for constructors". I find these container objects a lot when working with database-heavy stuff. And if the other side is a web application, decent parameter validation makes sense.

I'm using other fancy helpers for constructors like coercion and BUILDARGS almost exclusively when I want to retain the API from a non-Moose constructor to avoid version dependencies.

On the other hand, I have programs where attributes and accessors are almost exclusively used from within the module itself and external uses are through "higher level" functions. For such programs, object inheritance with its method modifiers and in particular roles play a much greater role than the constructor which in itself sometimes is used only internally, exposing factory functions to the outside. Users of these modules (well, mostly I myself) don't even need to know the attributes, but as a developer I'm happy to have them around for debugging.

Hm, I am not a student of OOP theory, but I find that "most of what Moo faciliates" is not so much in the instance constructor but in attribute declarations, of which I typically have many times more than constructor params. I find that triggers, clearers, predicates and lazy builders etc. are among the main features of the framework, and they are for all attributes declared.

I don't normally find a problem with having a RO "accessor" derived from declaring an attribute in order to take a named constructor param, but if you really don't want its value to be available to consumers you could maybe do something with BUILDARGS?

package Foo {
    use Moo;

    has qux => (is => 'ro');

    around BUILDARGS => sub {
        my ($orig, $class, $args) = @_;
        return {
            qux => $args->{bar} * $args->{baz},
        };
    };
};

use strict;
use warnings;
use feature 'say';

my $o = Foo->new({
    bar => 6,
    baz => 7,
});

say $o->qux;
say $o->bar;
[download]

$ perl 11107488.pl

42
Can't locate object method "bar" via package "Foo" at 11107488.pl line
+ 24.
[download]

Hope this helps!

Yes, I could do that all in BUILDARGS, but "look at how tedious that is", when compared with doing the stuff as (fake) accessors. In a way this feels to me like Java where every data structure has to become a class.

The following is a helper (role) that merely ingests either a premade dbh, or otherwise, a db username, db password and a DSN, to use DBI to make the DBH from:

package Moo::Role::DBIConnection;
use Moo::Role;
use Filter::signatures;
use feature 'signatures';
no warnings 'experimental::signatures';
use DBI;

our $VERSION = '0.01';

=head1 NAME

Moo::Role::DBIConnection

=head1 SYNOPSIS

    { package My::Example;
      use Moo 2;
      with 'Moo::Role::DBIConnection';
    };

    # Connect using the parameters
    my $writer = My::Example->new(
        dbh => {
            dsn  => '...',
            user => '...',
            password => '...',
            options => '...',
        },
    );

    # ... or alternatively if you have a connection already
    my $writer2 = My::Example->new(
        dbh => $dbh,
    );

=cut

has 'dbh' => (
    is => 'lazy',
    default => \&_connect_db,
);

has 'dsn' => (
    is => 'ro',
);

has 'user' => (
    is => 'ro',
);

has 'password' => (
    is => 'ro',
);

has 'options' => (
    is => 'ro',
);

sub _connect_db( $self ) {
    my $dbh = DBI->connect(
        $self->dsn, $self->user, $self->password, $self->options
    );
}

1;
[download]

Somehow, I think shouldn't have to make the dsn, name and password accessors just so I can use them from _connect_db, and ideally, there would be a nicer thing that implements what the Moo*-supplied ->new() does, except that it expects just a hashref, instead of expecting accessors on $self.

But I haven't seen that yet, so it's not really a feature I'd want to see in Perl 7. If it happens for Perl 7 that would be doubly great, of course!

Ah, I've stumbled over this: Parameters which are only needed at object creation, but which don't need to stick around (or shouldn't, in the case of a password).

Contrary to my previous post, where I advocated to use this only to keep APIs compatible, this is another example where I find coercion to be an excellent tool. Something sort of like this (note I'm not familiar with Moo coercion which seems to be different from Moose coercion, so caution is advised):

package Moo::Role::DBIConnection;
use Moo::Role;
use feature 'signatures';
no warnings 'experimental::signatures';
use DBI;

our $VERSION = '0.01';

=head1 NAME

Moo::Role::DBIConnection

=head1 SYNOPSIS

    { package My::Example;
      use Moo 2;
      with 'Moo::Role::DBIConnection';
    };

    # Connect using the parameters
    my $writer = My::Example->new(
        dbh => {
            dsn  => '...',
            user => '...',
            password => '...',
            options => '...',
        },
    );

    # ... or alternatively if you have a connection already
    my $writer2 = My::Example->new(
        dbh => $dbh,
    );

=cut

has 'dbh' => (
    is => 'ro',
    coerce  => \&_coerce_db,
);

sub _coerce_db {
    my $connection_data = shift;
    return UNIVERSAL::isa($connection_data,'DBI::db') ?
        $connection_data :
        DBI->connect( @$connection_data{qw(dsn user password options)}
+ );
}

1;
[download]

Edited to add: 1nickt was faster and more comprehensive with the same proposal. I upvoted his, feel free to ignore mine.

I think I would use a coercion to simplify that, and, yes, shed the unwanted attributes (accessors). Note I dropped the signatures as I don;t have the Filter module installed, but also no longer needed.

package Moo::Role::DBIConnection {
    use Moo::Role;
    use DBI;

    has 'dbh' => (
        is       => 'ro',
        required => 1,
        coerce   => sub {
            my $args = shift;
            return $args if ref($args) eq 'DBI::db';
            ref($args) eq 'HASH' or die 'Not a DB handle nor a hashref
+';
            return DBI->connect( @{$args}{qw/dsn user password options
+/} );
        },
    );
};
[download]

##
# testing

package MyClass {
    use Moo;
    with 'Moo::Role::DBIConnection';
};

use Test::Most 'die';

my %args = (
    dsn      => 'dbi:mysql:database=mysql',
    user     => 'ntonkin',
    password => undef,
    options  => { RaiseError => 1 },
);

subtest 'With no args' => sub {
    dies_ok sub { my $o = MyClass->new }, 'exception on no args';
};

subtest 'With bad type' => sub {
    throws_ok { my $o = MyClass->new(dbh => [\%args]) } qr/Not a DB ha
+ndle nor a hashref/;
};

subtest 'With existing handle' => sub {
    my $dbh = DBI->connect( @args{qw/dsn user password options/} );
    cmp_ok( $dbh->do('select count(*) from db'), '>', 0, 'Found a DB' 
+);
    my $o = new_ok('MyClass', [dbh => $dbh], 'No exception with handle
+ passed in');
    cmp_ok( $o->dbh->do('select count(*) from db'), '>', 0, 'Found a D
+B via obj');
};

subtest 'With bad params' => sub {
    local $args{user} = 'frobnicator';
    throws_ok { my $o = MyClass->new(dbh => \%args) } qr/coercion for 
+"dbh" failed/;
    throws_ok { my $o = MyClass->new(dbh => \%args) } qr/Access denied
+ for user/;
};

subtest 'With params' => sub {
    my $o = new_ok('MyClass', [dbh => \%args], 'No exception with args
+ hash passed in');
    cmp_ok( $o->dbh->do('select count(*) from db'), '>', 0, 'Found a D
+B via obj');
    dies_ok sub { print $o->dsn }, 'No DSN accessor!';
};

done_testing;
[download]

Output:

$ prove -lrv 11107494.pl

11107494.pl ..
# Subtest: With no args
    ok 1 - exception on no args
    1..1
ok 1 - With no args
# Subtest: With bad type
    ok 1 - threw Regexp ((?^:Not a DB handle nor a hashref))
    1..1
ok 2 - With bad type
# Subtest: With existing handle
    ok 1 - Found a DB
    ok 2 - 'No exception with handle passed in' isa 'MyClass'
    ok 3 - Found a DB via obj
    1..3
ok 3 - With existing handle
# Subtest: With bad params
    ok 1 - threw Regexp ((?^:coercion for "dbh" failed))
    ok 2 - threw Regexp ((?^:Access denied for user))
    1..2
ok 4 - With bad params
# Subtest: With params
    ok 1 - 'No exception with args hash passed in' isa 'MyClass'
    ok 2 - Found a DB via obj
    ok 3 - No DSN accessor!
    1..3
ok 5 - With params
1..5
ok
All tests successful.
Files=1, Tests=5,  0 wallclock secs ( 0.01 usr  0.00 sys +  0.09 cusr 
+ 0.01 csys =  0.11 CPU)
Result: PASS
[download]

Hope this helps!

update: added test for bad type and moved isa check to coercion



The way forward always starts with a minimal test.