in reply to Re: Function signatures in POD-headlines/pseudo code! Is there a standard?
in thread Function signatures in POD-headlines/pseudo code! Is there a standard?

It simply lists all possible call syntaxes, using upper case letters for metasyntactic elements.

I prefer the sigil notation since

\@rows
is much more expressive than
EXPR
or even
ARRAYREF
at no cost.

The system works for builtins since they operate on simple inputs, but it doesn't scale well to the more complex requirements of modules and classes.

Replies are listed 'Best First'.
Re^3: Function signatures in POD-headlines/pseudo code! Is there a standard?
by LanX (Saint) on Dec 07, 2009 at 18:52 UTC
    there is another trap...

    @coordinates

    could either mean

    • a list of 4 scalars (a 4-tuple) (like in Corion's code, where he wanted the clipping rectangle defined)
    • or an array which is taken per reference, because of the prototype (like in shift)

    How do you solve this?

    Cheers Rolf

    PS: I expect you now to say that you always avoid prototypes, right? ;-)

      I would list the four scalars if I wanted four scalars. You can always define the format of @coordinates at the top and use that, but I don't see any gain in doing so.

      The name of a variable can only tell so much. Extra limitations (e.g. that it must be an array) can be documented below.

      I expect you now to say that you always avoid prototypes, right? ;-)

      Close. I tend to write classes, and prototypes don't apply to methods.

      or an array which is taken per reference, because of the prototype (like in shift)

      Method calls are not influenced by prototypes

      sub Y::Pushy(\@){ warn join ' ', map {"($_)"} @_, ''; } my @blah = 1 .. 2; Y::Pushy @blah; Y->Pushy(@blah); __END__ (ARRAY(0x3d8bbc)) () at - line 2. (Y) (1) (2) () at - line 2.