Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?
 
PerlMonks  

Subroutine Bewilderment

by dimar (Curate)
on May 29, 2004 at 07:00 UTC ( #357432=perlquestion: print w/ replies, xml ) Need Help??
dimar has asked for the wisdom of the Perl Monks concerning the following question:

The Observation

While studying up on Perl to get 'big picture' insights, something hit me. Perl has a bewildering arsenal of subroutine DECLARATION and CALLING syntax options. These options can interact and conflict with each other in complicated ways. In other words, depending on how you organize your code, you can construct code in such a way that your subroutines ...

  • MUST be CALLED with commas separating the arguments
  • MUST NOT be CALLED with commas separating the arguments
  • MAY be CALLED with commas separating the arguments
  • MAY be CALLED with a leading ampersand
  • MUST NOT be CALLED with a leading ampersand
  • MUST be CALLED with a leading ampersand
  • MUST be CALLED with parenth around arguments
  • MUST NOT be CALLED with parenth around arguments
  • MAY be CALLED with parenth around arguments
  • MUST be CALLED with a specific number of arguments
  • MAY be CALLED with any number of arguments
  • MAY be CALLED before it is DECLARED in your code
  • MAY be CALLED before it is DECLARED and DEFINED in your code
  • MUST NOT be CALLED before it is DECLARED in your code
  • MUST NOT be CALLED before it is DECLARED and DEFINED in your code
  • MAY be DECLARED using parenth (aka prototype) between sub NAME and CODEBLOCK

The Question

Is there a 'big picture' way to comprehend how these options relate to one another? Is there a synergistic rationality behind it that someone can say in one or two sentences? Is it basically the historical trends of the language that has resulted in this matrix of options? Any insight welcome.

Note: for purposes of this post, the terms "MUST" and "MUST NOT" are defined as "violating this rule will cause a either a warning message under 'use warnings' or an error message, or both."

Comment on Subroutine Bewilderment
Re: Subroutine Bewilderment
by Joost (Canon) on May 29, 2004 at 08:59 UTC
    Calling conventions
    Unless you really, really know what you're doing you should use subroutine($arg1,$arg2); to call any subroutine. AFAIK there is now no type of subroutine that MUST be called with a leading ampersand or without comma's seperating the arguments.

    For methods; always use $object_or_class->methodname($arg,$arg2);

    prototypes
    If you use prototypes you can make it a little easier to use the other calling conventions but in general it's not needed unless you really want to write a subroutine that looks like a sort of operator on code blocks. Be sure to read up on prototypes before use, and only use them when you really need to.

    defining and use of subs
    If you don't use the default calling convention, you should define your subs (or a stub) before calling them. Subroutines that use "external" lexical variables that need to be intialized before calling should also be defined before calling (but that's just because you probably want the lexical initialisation near the definition of the sub).

    summary
    If you want to be safe, define your subs first and always use subroutine($arg,$arg2) unless you have a good reason not to.

    Joost.

      AFAIK there is now no type of subroutine that MUST be called with a leading ampersand or without comma's seperating the arguments
      hmmm ... I could have emphasized more the 'definition' I was considering for MUST and MUST NOT. In other words, think of it like a kind of puzzle, can I write code in such a way that violating the rule will cause an error or a warning?. Then, if you find an answer to the puzzle, consider whether the code is likely to happen in the 'real world' ... if 'yes', then you have a candidate for MUST and MUST NOT. I have found this approach to be useful because it essentially asks "how many different ways can I (legally) say the same thing?"

      For example, here is code that illustrates the ampersand 'rules'.

      ### init use strict; use warnings; ### ampersand variants fooFunc (1,2); ### ok, ampersand optional &fooFunc(1,2); ### ok, apersand optional #foneFunc(1,2); ### NOT ok, called too early &foneFunc(1,2); ### ok, ampersand required #fwoFunc(1,2); ### NOT ok, too early &fwoFunc(1,2); ### ok, ampersand required print "\n--------------------------\n"; sub fooFunc { if($_[0]){print "fooFunc arg0: ". $_[0] ."\n"} if($_[1]){print "fooFunc arg1: ". $_[1] ."\n"} print "-------------\n"; } sub foneFunc() { if($_[0]){print "foneFunc arg0: ". $_[0] ."\n"} if($_[1]){print "foneFunc arg1: ". $_[1] ."\n"} print "-------------\n"; } sub fwoFunc($$){ if($_[0]){print "fwoFunc arg0: ". $_[0] ."\n"} if($_[1]){print "fwoFunc arg1: ". $_[1] ."\n"} print "-------------\n"; }

      As far as a subroutine call where separating commas MUST NOT be included, consider a user-defined subroutine that works like map CODEBLOCK ARRAY putting a comma between CODEBLOCK and ARRAY causes error.

      Note that we don't run into problems until we start introducing prototypes, which generally people say to "stay away from", which is fine, but with caveats...

      • For someone used to programming in JavaScript (for example) it's not entirely obvious that fooFunction() is anything more than just a bare declaration of a subroutine name (as opposed to a 'prototype' embodied in the empty parenth).
      • You can only 'stay away' from something for so long, and then finally you want to become one of those mythical people who 'really really really know what they are doing'
      • It's interesting to know whether the 'stay away' items are either 1) legacy stuff that is going to be deprecated, or 2) advanced stuff that will remain for those who wish to delve deeper.
      • It seems like some 'stay away' items that are advanced, overlap with 'stay away' items that are to be deprecated.

        Note that we don't run into problems until we start introducing prototypes, which generally people say to "stay away from", which is fine, but with caveats...
        Well... that's what prototypes are meant for: breaking the rules, and that entails you're taking the risk of confusing the users of your library, the perl parser, or both.

        You can only 'stay away' from something for so long, and then finally you want to become one of those mythical people who 'really really really know what they are doing'
        I understand your concern, but I can only repeat the above paragraph. The phrase "enough rope to hang yourself" comes to mind.
Re: Subroutine Bewilderment
by thospel (Hermit) on May 29, 2004 at 11:59 UTC
    Simply always use the same basic style. By the time you are sophisticated enough to have special needs, you'll probably also know how to do that special thing, or you can look it up.

    Definition:

    sub foo { ...code... }
    Use:
    foo($arg1, $arg2);
Re: Subroutine Bewilderment
by rir (Vicar) on May 29, 2004 at 13:43 UTC
    I will agree with Joost except that you also need to become used to print and similar functions.
    print SPECIAL_ARG ordinary_arg_list, with_commas;
    This is the only unusual construction that you need to get used to early on. Otherwise arguments are separated by commas.

    Generally, just don't use the ampersand prefix and just don't use prototypes.

    Regarding predeclaration or definition, use use strict and use warnings and let perl train you.

    Your question is a good one and well worth better answers than you are apt to get. The problem is that your question embraces many aspects of Perl syntax and there is no short definitive answer.

    There is a lot of sense in Perl. I think you just need to grapple with her for a while and you will get her big picture. Attack smaller bits of your problem and use a more empirical method to learn. Perl is one of the more grown computer languages, versus spec'd; practice is a bigger part of learning due to this.

    Knowing the precedence of op's, what defines a list, and what is happening with context; knowing those will help with the issues you ask about.

    Be well.

      print SPECIAL_ARG ordinary_arg_list, with_commas;
      This is the only unusual construction that you need to get used to early on. Otherwise arguments are separated by commas.

      The syntax may be a little unusual, mostly because it's not used much except with print and printf, but it isn't unique to those functions. It's just the indirect object syntax, new Foo, frobnicate $foo "bar", etc. It's covered in perlobj, and it is generally to be avoided except with builtins.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://357432]
Approved by davido
Front-paged by cLive ;-)
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others about the Monastery: (10)
As of 2014-09-17 16:19 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (91 votes), past polls