in reply to sub ($self,$var,@arr) {}

sub ($self, $var, @arr) {
  ...
}

## versus

sub {
  my ($self, $var, @arr) = @_;
  ...
}

[download]
Total Savings = 6 keystrokes (not including spaces)

This wouldn't add new functionality, and saving a few keystrokes is less important, IMHO, than maintaining consistency.

Understanding what @_ is, how it works, and how to use it is a Good Thing; it takes some of the mystery out of parameter passing, and is conceptually related to many other important Perlisms that beginners often struggle with (eg. $_, local, aliases). Offering Perl beginners an easy way out by not learning about @_ would be doing them a disservice. @_ allows for many interesting possibilities that fixed parameter lists do not (for instance, "overloaded" subs). It would also be unfortunate if Perl's worth were diluted by encouraging people to code like it's just another scripting language. My gut feeling is that if you were to add such a syntax, newcomers to the language would use it almost exclusively, and @_ would evolve into an unusual, depricated construct of interest primarily to obfuscators.

And I don't want Perl to look any more like C, C++, or Java than it has to ;) Bad memories, you know?

That said, your suggestion is in keeping with the idea that TIMTOWTDI, and I don't see how it could break backwards-compatibility or be difficult to implement. It would also add some sanity, from an aesthetic perspective, to Perl's prototyping system.

So I don't quite know on which end of this issue I sit. Perhaps, I'll just offer the annoying cliche "if it ain't broke..."

Replies are listed 'Best First'.
Re: Re: sub ($self,$var,@arr) {}
by tadman (Prior) on Feb 09, 2001 at 22:54 UTC
    Perhaps raptor was hinting at the way C used to reference parameters, K&R style, which is a little outdated: 
          int main (argc, argv)
         int argc,
         char *argv[]
      {
           return 0;
      }

    [download]
    Still, I find it nice that Perl allows you to use the parameters any way you wish, which is especially useful when you're passing parameters using the HASH-style methods, such that you really don't know how many parameters you are going to receive, nor what type they are: 
          MyFunc ( -type  => qw ( lemur llama lynx ),
               -width => 150 );

    [download]
    It is interesting that CGI.pm uses parameters in a way that is not unlike UNIX-style command-line arguments in terms of the way they are parsed and processed.

    The prototypes introduced in 5.6(?) go a long way towards ensuring that your module is used properly, and detecting errors in parameters vs. errors in the module: 
           sub MyFunc ($$\$)
       {
             my ($x, $y, $z) = @_;
             # $x and $y are required, $z optional.
       }

    [download]
    Although MeowChow doesn't "want Perl to look any more like ... C,C++ or Java", that is no reason to not borrow methods and practices from these languages that were implemented with solid reasoning. The cliché "if it ain't broke" certainly hasn't been heeded by the Perl developers, Larry Wall included, because Perl 4.0 was hardly broken, and just when you think it couldn't get any better, it did!
[reply]
[d/l]
[select]
Re: Re: sub ($self,$var,@arr) {}
by raptor (Sexton) on Feb 13, 2001 at 16:38 UTC
    ok I think that
    prototypes are GOOD thing, but current implementation doesn't help US alot :")
[reply]

In Section Seekers of Perl Wisdom