On Thu, Apr 2, 2009 at 13:18, Gunnar Hjalmarsson <nore...@gunnar.cc> wrote:
snip
> Another thing is that I was a little surprised to see that a book written by
> Randal contains an example where a function is called with & before the
> name. It's not just a matter of taste, but the & character changes the
> behavior of the called function in some situations.
>
> http://perldoc.perl.org/perlsub.html
snip
It started in the 3rd edition of Learning Perl. Here is a thread[1]
where brian d foy and Randal Schwartz defend telling people to do
something they will almost never want to do. I still don't buy it,
but they are the professional Perl trainers[2]. They also teach new
users to say foreach early in the book and then later tell them to use
for instead:
That's really a foreach loop, but it's written for. Except for that
one example, all through this book, we'll spell out foreach wherever
it appears. But in the real world, do you think that Perl folks will
type those extra four letters? Excepting only beginners' code, it's
always written for, and you'll have to do as Perl does and look for
the semicolons to tell which kind of loop it is.
I can sort of see a case for this; making a beginner figure out which
type for loop you are talking about by looking at its structure is
probably a mistake.
snip
> There is no reason in this case to use the & character, and most Perl
> programmers today would say that
>
> which_element_is("dan", @names);
>
> is the preferred 'normal' way to call a function.
snip
In fact, using & blindly can cause problems because prototypes are
ignored when you use &. This is why they don't use & on the front of
core functions like print. Of course, this leads to (in my mind at
least) an even worse confusion in the readers mind: when calling core
functions you should say func(), but when calling user defined
functions you should say &func().
#!/usr/bin/perl
use strict;
use warnings;
#this print will fail at compile time
#because & causes prototypes not to
#be used and perl doesn't see STDOUT
#as a filehandle, since the failure
#is at compile time I can't even use
#block eval to trap it, I must use
#the evil string eval
eval '
&print(STDOUT "hello\n"); 1;
' or do {
print $@;
};
#this one works just fine
print(STDOUT "hello\n");
Of course, all of this could be masterful social conditioning: they
tell readers to use &func(), the readers inevitably post a question
somewhere, and people detail the problems surrounding &func() without
Schwartz, et al. ever having to put them in the book (making the book
smaller and more approachable)[3].
1. http://www.nntp.perl.org/group/perl.beginners/2008/04/msg100013.html
2. There is a tiny, cynical part of my brain that says "yeah, and if
the book is confusing enough you will have to hire them", but I try
not to listen to it because that part of me is stupid and thinks
doctors don't really want to make you well because their income source
would dry up.
3. There goes that part of my brain again, don't listen to a word it says.
--
Chas. Owens
wonkden.net
The most important skill a programmer can have is the ability to read.
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/
