Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

hdp (1658)

  (email not shown publicly)
+ -

  Comment: Re:Immutable objects (Score 1) on 2010.08.15 8:41

by hdp on 2010.08.15 8:41 (#72317)
Attached to: Why does Object::Tiny only support getters

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.

Read More 2 comments
Comments: 2
+ -

  Comment: +1 (Score 1) on 2010.06.25 21:39

by hdp on 2010.06.25 21:39 (#72125)
Attached to: YAPC::NA2010 wrap-up

This is probably my favorite post of yours.

Read More 1 comments
Comments: 1
+ -

  Comment: the functional version (Score 1) on 2010.01.22 21:28

by hdp on 2010.01.22 21:28 (#71568)
Attached to: Code generation and stone soup

while is just sugar for recursion.

Read More 9 comments
Comments: 9
+ -

  Comment: "when an inherited method is being overridden" (Score 1) on 2009.10.14 8:44

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?

Read More 20 comments
Comments: 20
+ -

  Comment: I switched to blogger (Score 1) on 2009.10.02 17:25

by hdp on 2009.10.02 17:25 (#70765)
Attached to: Migrate from use.perl to ...?

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

Read More 7 comments
Comments: 7
+ -

  Comment: aggregators (Score 1) on 2009.06.01 10:52

by hdp on 2009.06.01 10:52 (#68890)
Attached to: Perl Saves The Day & Plea For Help
Comments: 1
+ -

  Comment: Re: be more specific (Score 1) on 2009.05.03 20:40

by hdp on 2009.05.03 20:40 (#68435)
Attached to: Beginning to administer perl on Ubuntu

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.

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.

Read More 3 comments
Comments: 3
+ -

  Comment: be more specific (Score 1) on 2009.05.03 19:41

by hdp on 2009.05.03 19:41 (#68434)
Attached to: Beginning to administer perl on Ubuntu

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?

Read More 3 comments
Comments: 3
+ -

  Comment: do not squash (Score 1) on 2009.04.25 20:33

by hdp on 2009.04.25 20:33 (#68314)
Attached to: seeking git wisdom: to squash or not to squash

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.

Read More 4 comments
Comments: 4
+ -

  Comment: not knowing Perl or not knowing good practice? (Score 1) on 2009.03.28 11:27

by hdp on 2009.03.28 11:27 (#67931)
Attached to: How Padre saved my day

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'.)

Read More 2 comments
Comments: 2
+ -

  Comment: parameterized roles (Score 1) on 2009.03.18 23:15

by hdp on 2009.03.18 23:15 (#67861)
Attached to: Role Oriented Programming

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}

Read More 27 comments
Comments: 27
+ -

  Comment: Re:What is this reality you speak of? (Score 1) on 2009.02.22 23:29

by hdp on 2009.02.22 23:29 (#67557)
Attached to: The Secret Life Of Whitespace REVEALED!

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

Read More 18 comments
Comments: 18