Ben and Tassilo: about calling subs with &

[Rex Gustavus Adolphus]

Hi!

A couple of months ago I participated in a thread "What with this open
file..."

I published parts of my code in it and that lead into a discussion
about not calling subs with & (started by Ben Morrow):
"Don't call subs with & unless you need to (here you don't)."

Well I just looked into one of the books I used to learn Perl (aptly
named "Learning Perl"(!))

Accidently the chapter about subroutines is published on the web,
see http://www.oreilly.com/catalog/lperl3/chapter/ch04.html

Quoting from the beginning of Chapter 4 Subroutines:
"The name of a subroutine is another Perl identifier (letters, digits,
and underscores, but can't start with a digit) with a
sometimes-optional ampersand (&) in front. There's a rule about when
you can omit the ampersand and when you cannot; we'll see that rule by
the end of the chapter. For now, we'll just use it every time that
it's not forbidden, which is always a safe rule"

And another quote from the end of the same chapter:
"So, the real rule to use is this one: until you know the names of all
of Perl's builtin functions, always use the ampersand on function
calls."


So now, Ben and Tassilo, you maybe understand way programmers new to
Perl uses & in subroutine calls?

Have a good weekend : )

 

[Tore Aursand]

Well I just looked into one of the books I used to learn Perl (aptly
named "Learning Perl"(!))
[...]

I hope it have been updated;

perldoc -q calling
perldoc perlsub

 

[Tassilo v. Parseval]

Also sprach Rex Gustavus Adolphus:

A couple of months ago I participated in a thread "What with this open
file..."

I published parts of my code in it and that lead into a discussion
about not calling subs with & (started by Ben Morrow):
"Don't call subs with & unless you need to (here you don't)."

Well I just looked into one of the books I used to learn Perl (aptly
named "Learning Perl"(!))

Accidently the chapter about subroutines is published on the web,
see http://www.oreilly.com/catalog/lperl3/chapter/ch04.html

Quoting from the beginning of Chapter 4 Subroutines:
"The name of a subroutine is another Perl identifier (letters, digits,
and underscores, but can't start with a digit) with a
sometimes-optional ampersand (&) in front. There's a rule about when
you can omit the ampersand and when you cannot; we'll see that rule by
the end of the chapter. For now, we'll just use it every time that
it's not forbidden, which is always a safe rule"

And another quote from the end of the same chapter:
"So, the real rule to use is this one: until you know the names of all
of Perl's builtin functions, always use the ampersand on function
calls."


So now, Ben and Tassilo, you maybe understand way programmers new to
Perl uses & in subroutine calls?

Quite. If you re-read the thread you quoted you will notice that I did
not at all condemn the ampersand on function calls. In essence I said:
If a programmer sees advantages in it (even if it is just for the sake
of feeling more comfortable), there is nothing wrong with them. The
side-effects they have are almost neglectible and they are further cut
down by 50% when parens are used.

Tassilo

 

[Chris Richmond - MD6-FDC ~]

perldoc perlsub

Please correct this summarization if needed:

You shouldn't use '&' when calling new-style subroutines that have been
declared with prototypes because it disables arg checking.
Otherwise, its still optional when calling with parens, required
without, unless the subroutine is predeclared.

Chris

 

[Uri Guttman]

CR> Please correct this summarization if needed:

CR> You shouldn't use '&' when calling new-style subroutines that
CR> have been declared with prototypes because it disables arg
CR> checking. Otherwise, its still optional when calling with
CR> parens, required without, unless the subroutine is predeclared.

you forgot the case where &foo without parens will pass the current @_
directly to the called sub. and the other point is that it is considered
poor style. learning perl is just that, learning. note that the book
said only until you know the names of perl functions so you won't use
those for sub names. that should take too long for most perl newbies.
any perl users beyond that stage shouldn't use & for sub calls. and i
would even just teach foo() to newbies and never mention & except for
getting a code ref with \&foo.

uri

 

[Tad McClellan]

Please correct this summarization if needed:

You shouldn't use '&' when calling new-style subroutines that have been
declared with prototypes because it disables arg checking.
Otherwise, its still optional when calling with parens, required
without, unless the subroutine is predeclared.

Corrections are not needed there.

What did you think needed changing?

 

[Tad McClellan]

A couple of months ago I participated in a thread "What with this open
file..."

I published parts of my code in it and that lead into a discussion
about not calling subs with & (started by Ben Morrow):
"Don't call subs with & unless you need to (here you don't)."

Well I just looked into one of the books I used to learn Perl (aptly
named "Learning Perl"(!))

I am familiar with that book.

Accidently the chapter about subroutines is published on the web,
see http://www.oreilly.com/catalog/lperl3/chapter/ch04.html

Quoting from the beginning of Chapter 4 Subroutines:
"The name of a subroutine is another Perl identifier (letters, digits,
and underscores, but can't start with a digit) with a
sometimes-optional ampersand (&) in front. There's a rule about when
you can omit the ampersand and when you cannot; we'll see that rule by
the end of the chapter. For now, we'll just use it every time that
it's not forbidden, which is always a safe rule"

And another quote from the end of the same chapter:
"So, the real rule to use is this one: until you know the names of all
of Perl's builtin functions, always use the ampersand on function
calls."

I have to teach it that way because Randal wrote it that way,
and he's the boss.

But after teaching it that way, I point out that I _never_ use
ampersands on function calls (since he isn't there to stop me).

I tell them: always use parens, never use ampersands, and if you
get strange behavior from your user-defined function, try

perldoc -f myfunc

and see if you chose a name that is already being used.


I like my way, because then they don't have to detect the
"inflection point" between beginner and not-beginner and
change the way they've been doing things.

So now, Ben and Tassilo, you maybe understand way programmers new to ^^^
Perl uses & in subroutine calls?

Right, and Ben and Tassilo are helping them to move away from the "new" part.

Beginners aren't likely to be using prototypes, so it doesn't make
any difference.

But we expect that they will progress beyond "beginner" at some point,
which is when ampersands can bite them.