See RFC: automating modular classes
How Large Does Your Project Have To Be to Justify Using Moose?
Re: How Large Does Your Project Have To Be to Justify Using Moose? (modular)
Re^3: How Large Does Your Project Have To Be to Justify Using Moose? (modular)
Re: Object accessors with unknown data (hash)
Re: $class = ref($class) if ref($class) Redux (theory)
Re^7: MooseX obscure error and importance of Unit Testing (public attributes, generated accessors)
RFC: automating modular classes

Re response time. Unless you did not have XS Mouse installed this is impossible. Mouse with XS will beat Moo in all equivalent use cases.

That would have been my guess too, but the author of Moo had a similar experience e.g.

I've tried several times to use Mouse but it's 3x the size of Moo and takes longer to load than most of my Moo based CGI scripts take to run.

That's from https://metacpan.org/pod/release/HAARG/Moo-1.007000/lib/Moo.pm#WHY-MOO-EXISTS

Hmmm… still sounds anecdotal to me and contrary to some admittedly casual tests wherein Mouse was ever so slightly the pure load winner. I’d like to see proof.

Note, I prefer Moo—because I like its syntax and rarely need the deeper meta-protocols—and almost always reach for it. The speed argument strikes me as false and and the benchmarks I have seen bear this out strongly.

Thanks for the follow-up and no problem with rephrasing the question.

Up until you posted this, I hadn't seen any discussion regarding Moo being anti-modular.

I don't know if the concern here is that Moo readily implements a poor modular design, or that Moo generates poor code from a good design.

I've designed my interfaces and started to code the framework in Moo. I see no lack of modularity at all at this stage. I'd be interested in any heads-up regarding problems that (perhaps you think) will present themselves later on.

There has been previous discussion of Moose being anti-modular (the Anonymous monk has given links to some of those), and those arguments apply to Moo as well, even more so.

The concern here is that using Moo leads to code which is un-modular. A simple example showing how easy it is to go off the modular path is in this subthread, which was looking at how to implement a bounded queue.

Logically, the operations such a queue should support are "new" (construction), "push" (adding an item) and "pop" (removing an item). In a hand crafted solution this is exactly what you get. But in a Moo solution you also get an operation called "items" that returns the underlying array ref. This defeats encapsulation, so is un-modular (it would be like putting a button on an ATM that allowed regular users to dump out all the cash). An example showing this version of the queue is not bounded after all.

An interface with, say 20 methods is harder to change/support than one with 5 methods, yet with Moo you typically end up with fat leaky interfaces, because all the attributes are part of the interface. With Moose you can avoid this by declaring an attribute as "bare", but Moo doesn't support this so the nearest approximation is to use a convention like $obj->_get_foo() (but neither of these practices seem common judging by what we see on CPAN).

The point of modularity is to make change easier by hiding implementation details behind an interface. Yet with Moo(se), by default those implementation details are exposed via accessors and the constructor (init_arg's). So to get modularity you have to avoid the defaults, which is tedious and hence very few people seem to do so.

++ Many thanks for this information (and my apologies for the late response - I've been caught up with other things over the last week).

You've made valid points regarding "fat leaky interfaces". I'll keep this in mind as I am coding.

-- Ken

So to get more modular, perhaps "namespace::onlykeep" or Moo::OnlyNew?

{
    package Foo;
    use Moo;
    has(('it', 'is', 'ro'));
    has(('bit', 'is', 'rw'));
    sub fit {
        warn $_[0]->bit, $_[0]->it;
    }
    use namespace::onlykeep qw/ fit new /;
    1;
}

use Data::Dump qw/ dd /;
my $f = 'Foo'->new('it', 'was', 'bit', 'ten');
dd($f);
$f->fit; ## should warn
dd($f->it, $f->bit); ## should die
[download]

Someone think of something please :)