Hacker News Reader

Comment by grout | Hacker News Reader

The readability arguments need to include such modules as Method::Signatures::Simple, which replaces the old manual method (no pun intended) with:

   method foo ($a, $b) {
      $self->blargh($a + $b);
   }

View on HN

What's been gained here? You've traded away one line of boilerplate Perl understood by all, and now everyone who touches your code has to know the semantics of 'method'.

... now everyone who touches your code has to know the semantics of 'method'.

The same argument applies for every new symbol imported into a namespace.

I personally prefer the internal source filter that we use at work (though at the end of the day, it is a source filter). A friend of mine got permission to open source it, but that died on the vine (I think that he got into MooseX::Declare, then Ruby and lost interest), and now he's not at the company anymore.

Is "my ($self, $a, $b) = @_" really that hard to read? It's slightly more characters but I've never found it particularly annoying.

I actually like the explicit "I'm reading from a special list" syntax because that's what it's doing. A lot of Perl's "ugliness" comes from the language being pretty honest about what it's doing.

Actually, though I tried C++ starting in 1993, Java from 1996, I didn't really grok OO until I tried it in Perl a few years later. Because it shows its guts out, without any sugar coating, I understood what it was about.

A favorite koan of mine: objects are a poor man's closures, but closures are a poor man's objects.

What's more readable?

Example 1 (my work's internal source filter format):

  sub function1( CODE $code, ARRAY $arr )
  {
    # body
  }

Example 2 (standard Perl):

  sub function1 {
    my ($code, $arr) = @_;
    die "Bad params." unless ref($code) eq "CODE"
                         and ref($arr)  eq "ARRAY";
    # body
  }

Example 3 (Method::Signature):

  func function1 (Code $code, Array $arr)
  {
    # body
  }

Yes examples 1 & 3 are much better. At some point signatures will be added to core Perl (class/method nearly made it into 5.16 as part of p5-mop proposal. Fingers crossed it will be in 5.18 next year).

When not using perl5i or playing with MooseX::Declare I will usually default to Params::Validate so your example would look like this:

  sub function1 {
    my ($code, $arr) = validate_pos( @_, {type => CODEREF}, {type => ARRAYREF} );
    ...
  }

The problem is in practice @_ is abused like crazy. For example:

1) I've often seen people shift from @_ half way in the middle of a function. If you really want to be certain about a method's formal parameters you have to read the entire function.

2) Also @_ is used in other circumstances which can cause mass confusion. For example Try::Tiny uses @_. It is difficult to guess if you getting a formal parameter or something else entirely (I"m not a fan of magic variables in case you can't tell). If you're Chromatic you might be able to know the probably hundred of uses of @_, but for a normal programmer you're screwed.

3) What if you want to use named parameters? You essentially have make a pointer to a hash, populate it, and unreference it. my $p = {'name' => 'val1', 'name2' => 'val2' }; f($p); sub f { my $name = $_[0]->{'name'}; my $name2 = $_[1]->{'name2'}; }

In other languages like python you can just do something like: def f(name, name2): ...

f(name = 'val', name2 = 'val2')

I've never seen a language handle function parameters as poorly as Perl. I forget almost all the Ruby I once knew but I'm pretty sure it is handled in a reasonable way similar to Python.

1) Adopt a convention of extracting your arguments at the beginning of the function.

Also, sometimes you just want to work on an arbitrary list of items. If you process one item and then shift it, that's a reasonable thing to do.

2. If you adopted the convention in 1, this shouldn't bite you. (I've never actually encountered this issue myself...)

3. You are misinformed. You can easily do something along the lines of:

    f({a => 'foo', b => 'bar'});
    
    sub f{ my ($args) = @_; say $args->{a}; }

There's probably a module of CPAN to do this even nicer.

Agreed. There is plenty of awful perl code out there. I have worked on codebases that did things like:

some_func(\%$some_object, \%some_hash);

and used variables like $a and $b as mainline code parameters...

However, if having dangerous features were something to hold against a language in general, nobody would be using C (maybe Linux in such an alternate universe would be written in Fortran or some other abomination). On the whole, I think that well-written Perl is very good. Poorly written Perl is... well, poorly written.

Thanks for the code sample and I like your convention. However, I can't enforce it on other people (especially at work) so it doesn't help me most of the time.

As for named parameters, the clean/simple style I like to use is:

do_stuff(Foo => 1, Bar => $baz);

sub do_stuff {

    my %args = @_;

    my $foo = $args{Foo};
    # etc...
}

Reply on news.ycombinator.com