in reply to What's the better Perl style? Define parameters or not?

"By using a parameter specification, you give Perl the capability to do valuable parameter checking."

First of all, it's called a prototype. Prototypes alter parsing rules. To say they provide parameter checking is bit of a stretch. There are better approaches if you want parameter validation.

The book "Perl for C Programmers" suggests you always define parameters.

Well that's pretty silly since a sub's prototype is ignored when the sub is called as a method. Since most of my subs are methods, it's suggesting I waste my time writing and maintaining prototypes that don't get used.

"Leaving out the parameter specification, an you invite chaos."

If that were true, the world would have ended in chaos a long time ago from all the OOP being done in Perl.

  • Comment on Re: What's the better Perl style? Define parameters or not?

Replies are listed 'Best First'.
Re^2: What's the better Perl style? Define parameters or not?
by jeanluca (Deacon) on Jan 05, 2010 at 07:32 UTC
    Well that's pretty silly since a sub's prototype is ignored when the sub is called as a method
    what!? A sub is a method right, so I assumed its called like one. Could you explain this to me ?

    cheers
    LuCa

    Update: thnx GrandFather, I never noticed this subtle difference!

      Consider:

      use strict; use warnings; my $obj = bless {}; # As function do_something (); # As method $obj->do_something (); sub do_something { my ($self) = @_; if ($self && 'main' eq ref $self) { print "Called as method\n"; } else { print "Called as function\n"; } }

      Prints:

      Called as function Called as method

      True laziness is hard work
      A sub is a method right, so I assumed its called like one.

      Prototypes change how the parser interprets the syntax of a call when Perl compiles the program. It's easy to figure out which apply() function gets called when you write:

      sub apply_arguments { my ($item, @args) = @_; for my $arg (@args) { apply( $item, @args ); } }

      It's much more difficult to figure out which apply() method gets called when you write:

      sub apply_arguments { my ($self, @args) = @_; for my $arg (@args) { $self->apply( @args ); } }

      The appropriate method may not even exist at that point in the program.

      I believe the difference is ambiguity. The procedural function is known and its signature can be examined and used. Depending on what you put in the signature, a %hash might be flattened into an @array, or converted into a \%hashref as it is shoved into @_. With a method call, you cannot be sure how a method call resolve until runtime, and by then it is too late to know what to do with the arguments.

      In Perl Best Practices, Damien recommends never using signatures. This is both because they are not available in all situations, and because they are easy to mess up. They are not worth the risk of potential problems.

      Personally, I like 'em. I don't use them for any OO work (obviously), but I do use them for procedural helper routines. This is because if I add or remove an argument and do not update it everywhere, I prefer to get the warning at compile time instead of something at runtime.

      - doug

      PS: Improved signatures is one of the perl6 things that I hope hurry up and get here.