use Perl

That article's irrelevant.

1) We're talking about named constructor arguments vs. attribute setters, not positional constructor arguments vs. attribute setters; we already know that named > positional for readability, maintainability, etc. in most cases. OK, now we also know that that's even true if the named arguments are spread out over several lines of code. Big deal.

2) How people interact with constructor arguments has absolutely nothing to do with the potential complexity of your objects introduced by letting attributes be changed not only immediately after construction but also 5 packages away and 12 scopes up.

This is probably my favorite post of yours.

while is just sugar for recursion.

Do you also want using 'sub foo {...}' to override a superclass method to be a compile-time failure or warning?

If not, why treat it differently than overriding a role method, other than one's comparative level of experience and familiarity with inheritance vs. with roles?

Yeah, it's boring, but it's also really, really easy to start using.

http://perlsphere.net/
http://ironman.enlightenedperl.org/

I got annoyed by your non-bug report enough to look at it myself and find that it pretty obviously doesn't work with anything but /usr/bin/perl.

http://github.com/hdp/CPANPLUS-Dist-Deb/tree/master

See if that helps. It still won't handle installs that are under a different top-level directory than /usr very well, if at all, and some of the directories are a bit dodgy (/usr/share seems hardcoded), but it will actually build a deb with a different perl.

What do you mean, it "assumes you'd only ever want to use the system perl"? what behavior is it displaying that you don't want?

I don't see any new bugs in the queue from you, and as a problem report, this post is pretty uninformative. Should I assume you don't actually want to get help, just to vent?

Once you throw away information, you can't get it back. Put the beautiful commit message into the merge commit if you must have it; I never find myself bothering. The "clutter" you mention is really a non-issue; git has powerful tools to browse/search history.

What does not knowing Perl when he wrote the program have to do with naming variables badly or using globals all over the place? I mean, those are things I'd expect a good programmer to avoid in any language. (Especially the variable naming, which doesn't even require knowledge of 'my' or 'local'.)

Moving along, were I to eliminate base classes, that would also eliminate this silliness:

        sub foo {
                my $proto = shift;
                my $class = ref $proto || $proto;
                die "You must override 'foo' in $class";
        }

That fires at runtime, not compile time. Just adding a requires qw'foo'; to your role and this becomes a compile-time failure.

Alternately, if the "foo" you're overriding there is (as it so often is) something like this:

sub foo_plugins {
    return ("My::Foo", "External::Library::Foo");
}

MooseX::Role::Parameterized might be a good option. e.g.

use MyRole => { foo_plugins => ["My::Foo", "External::Library::Foo" ] };

# elsewhere...
package MyRole;
use MooseX::Role::Parameterized;
parameter foo_plugins => (
    isa => 'ArrayRef[ClassName]',
    required => 1,
);
role {
    my $p = shift;
    method munge_stuff => sub {
        # do something for each @{$p->foo_plugins}
    };
};


Schwern
, I think you underestimate the productivity gains
; your quirky style is my well-tuned machine!