Q: the use of & in subroutine calls
The Glauber
sometimes and sometimes not. I'm curious if there is any formal or
informal consensus among the Perl gurus whether & should be used or
avoided.
Thanks!
glauber
--
Glauber Ribeiro
thegl...@my-deja.com
"Opinions stated are my own and not representative of Experian"
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
Randal L. Schwartz
The> Since the "&" in a sub call became optional, i've found myself using it
The> sometimes and sometimes not. I'm curious if there is any formal or
The> informal consensus among the Perl gurus whether & should be used or
The> avoided.
My intro training course recommends the initial use of &, until you
are much more familiar with all of the built-in keywords. Otherwise,
you may be puzzled as to why this fails:
log("starting");
do_some_task();
log("ending");
sub log {
printf LOGFILE localtime(time).": ", @_, "\n";
}
Yup. You've just used the built-in "log" function instead of yours.
Once you get smarter about looking at perlfunc, it's OK to drop the
ampersand.
print "Just another Perl trainer," # :)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<mer...@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Tye McQueen
) Since the "&" in a sub call became optional, i've found myself using it
) sometimes and sometimes not. I'm curious if there is any formal or
) informal consensus among the Perl gurus whether & should be used or
) avoided.
It appears to me that the consensus is that you generally don't
use C<&> on subroutine calls.
Some facts:
Using C<&> disables sub prototypes.
Not using C<&> adds minor limitations on subroutine names:
sub s { return "ess"; } # Just fine.
print &s(); # Also fine.
print s(); # Syntax error.
The C<&> is required for certain constructs:
$coderef= \&mysub;
goto &mysub;
Using C<&> w/o C<()> allows C<@_> to be preserved but this is frowned upon.
I think the more interesting question is whether or nor to use
C<()> on sub calls. I try to shoot for not using C<()> but
getting that to work requires:
Declare all subroutines before you use them. I usually do this
in part via a topological sort of subroutines within a file.
C<use strict> or I often won't know when I've failed at the above.
And it gets me compile-time checking of subroutine names [woohoo!].
--
Tye McQueen Nothing is obvious unless you are overlooking something
http://www.metronet.com/~tye/ (scripts, links, nothing fancy)
Randal L. Schwartz
Tye> It appears to me that the consensus is that you generally don't
Tye> use C<&> on subroutine calls.
"One school of thought" does not a "consensus" make. See my other post.
Ilya Zakharevich
<t...@metronet.com>],
who wrote in article <7r43l7$1...@beanix.metronet.com>:
> The C<&> is required for certain constructs:
> Using C<&> w/o C<()> allows C<@_> to be preserved but this is frowned upon.
Do not think so. This is an important optimization. When used in
non-tight loops it may be not *that* important, of course.
But definitely it should be used with care, since the callee will
change the "stack" of the caller:
perl -wle "sub a {shift} sub b {&a; print shift} b(1,2)"
2
Ilya
Jay Rogers
> >>>>> "Tye" == Tye McQueen <t...@metronet.com> writes:
>
> Tye> It appears to me that the consensus is that you generally don't
> Tye> use C<&> on subroutine calls.
>
> "One school of thought" does not a "consensus" make. See my other post.
The perlstyle manpage recommends not using & on a sub call.
Should we tell those learning Perl that perlstyle is just "one
school of thought" or that it represents a "consensus"?
However I do agree with Randal but from a code maintenance
standpoint. Yes removing &() reduces visual clutter, but it's
likely an important clue to some poor maintainer who's not that
familiar with the code or Perl's hundred some functions.
The old Camel book (1st edition) had a great section in it on how
to write code that was efficient from differing perspectives:
programmer time; machine time; maintainer time. Too bad that
lost out in the second edition to the module manpages :-)
--
Jay Rogers
j...@rgrs.com
Larry Rosler
0400, Jay Rogers <j...@rgrs.com> says...
...
> The old Camel book (1st edition) had a great section in it on how
> to write code that was efficient from differing perspectives:
> programmer time; machine time; maintainer time. Too bad that
> lost out in the second edition to the module manpages :-)
Blue Camel, 'Efficiency', pp. 537-546.
--
(Just Another Larry) Rosler
Hewlett-Packard Laboratories
http://www.hpl.hp.com/personal/Larry_Rosler/
l...@hpl.hp.com
Tom Christiansen
In comp.lang.perl.moderated,
Jay Rogers <j...@rgrs.com> writes:
:Yes removing &() reduces visual clutter, but it's
:likely an important clue to some poor maintainer who's not that
:familiar with the code or Perl's hundred some functions.
Larry intentionally allowed you to remove the ampersand. This is
the preferred notation in Perl5. By doing this, you get all kinds
of benefits:
0) it's easier to read without as much clutter.
1) list operator precedence, just like a built-in (usually)
2) prototype checking, like a built-in (if given)
3) protection from upstack mutilations by those you call
It simply violates the principle of least surprise that I should be able
to write:
sub fred() { return "finklestein" }
but then someone turns around and calls it as &fred. This is one of
the things that, under Larry's direction and explicit approval, I've
been careful to fix in all the Perl documentation, including the blue
ORA Perl books that I've worked on. You can spot a an old, perl4ish,
non-ORA, and/or non-lwallian book a league or seven away by its obsequious
allegiance to an ampersand.
Notice how the compiler is your friend:
% perl -wc
sub int { print "This is your int function\n" }
print int(3.5);
^D
Ambiguous call resolved as CORE::int(), qualify as such or use & at - line 2.
/tmp/a syntax OK
[ Exit 0]
or even better:
% perl -wc
sub log { return "This is your message: @_\n" }
print log("skullduggery")
^D
Ambiguous call resolved as CORE::log(), qualify as such or use & at - line 2.
Argument "skullduggery" isn't numeric in log at - line 2.
Can't take log of 0 at - line 2.
[ Exit 255 ]
Note well: those are *compile-time* messages. In fact, the last one
happens even if you should be so short-sighted as to omit the -w:
% perl -c
sub log { return "This is your message: @_\n" }
print log("skullduggery")
^D
Can't take log of 0 at - line 2.
[ Exit 255 ]
No problem -- you never make it to run time, boys.
--tom
--
SVR4 resembles a high-speed collision
between SVR3 and SunOS. - Dick Dunn
Ilya Zakharevich
<j...@rgrs.com>],
who wrote in article <823dwp8...@shell2.shore.net>:
> The perlstyle manpage recommends not using & on a sub call.
> Should we tell those learning Perl that perlstyle is just "one
> school of thought" or that it represents a "consensus"?
Depends on what you want to achieve. Lieing to newbies is a
well-known teaching technique.
Moreover, you substituted the question. The original discussion was
about C<&foo;>, not about C<&foo(1,2,3)> what perlstyle might have
discussed.
On the third hand, I found no mention of "&" or of a sub call in
perlstyle.
Ilya
Randal L. Schwartz
Ilya> Depends on what you want to achieve. Lieing to newbies is a
Ilya> well-known teaching technique.
Yes, our instructors say in the Learning Perl course on day one,
minute 3, "Some of what I will say over the next few days are lies, to
simplify things on the first round. There are often exceptions to the
rules I give you. If you're following along in the Llama book, you
will notice footnotes... this is where we lie in the text, but take it
back in the footnote. On first reading, skip the footnotes, but be
sure to read them someday so you know where we were lying."
And because I'm not teaching prototypes in Llama, teaching "mandatory
ampersand for this class" doesn't hurt them one iota, and has saved my
students more headaches over the long run. (I do mention them as
optional, but recommend they wait to play with that.)
print "Just another Perl trainer,"
--
The Glauber
mer...@stonehenge.com (Randal L. Schwartz) confessed:
[...]
> Yes, our instructors say in the Learning Perl course on day one,
> minute 3, "Some of what I will say over the next few days are lies, to
> simplify things on the first round. There are often exceptions to the
> rules I give you. If you're following along in the Llama book, you
> will notice footnotes... this is where we lie in the text, but take it
> back in the footnote. On first reading, skip the footnotes, but be
> sure to read them someday so you know where we were lying."
>
> And because I'm not teaching prototypes in Llama, teaching "mandatory
> ampersand for this class" doesn't hurt them one iota, and has saved my
> students more headaches over the long run. (I do mention them as
> optional, but recommend they wait to play with that.)
Allright, let's open another Pandora box...
What about prototypes? Opinions on them range from "they're useless" to
"they're evil". Are people using prototypes in the real world? Should
they?
g.
--
Glauber Ribeiro
thegl...@my-deja.com
print "Opinions stated are my own and not representative of Experian";
Tye McQueen
)
) What about prototypes? Opinions on them range from "they're useless" to
) "they're evil". Are people using prototypes in the real world? Should
) they?
I use them for _some_ not-general-purpose-routines (subs that are
only called from within the file where they are defined) as a
quick hack to warn me when I change the number of arguments that
the routine takes but forget to change all of the places that call
it. And even this hack is only half useful since I can't get Perl
to tell me when my topological sort of subs gets out of whack:
hick( "up" ); # This error is not caught.
sub hick ($$)
{
my( $dir, $dist )= @_;
warn "Moving $dist steps $dir.\n";
}
hick( "down", 2 ); # An error here would be caught.
And I don't use this hack on interesting subs that take optional
args, etc. But when I do use them in this hackish way, I sometimes
use \$, \@, \%, or & in addition to $. Outside of this cheap hack,
I think using \$, \@, or \% is more trouble than it is worth.
I see a use for them in implementing nice looking catch/throw but
I don't actually use them for that.
Other uses expose even more problems. See Tom C's recent posting
on this.
I tried to use them to coax a file handle argument into being a
reference to a glob in hopes of making the use of a bareword for
the file handle argument not generate a warning. It didn't work
for that and it replaced my informative usage message [which I've
come to depend on when using "perl -de 0"] so I wrote my own
"coerce into ref to glob" and dropped the prototype.
Tom Christiansen
In comp.lang.perl.moderated,
The Glauber <thegl...@my-deja.com> writes:
:Allright, let's open another Pandora box...
:What about prototypes? Opinions on them range from "they're useless" to
:"they're evil". Are people using prototypes in the real world? Should
:they?
I think you'll find that these should answer your question:
http://www.perl.com/pub/language/misc/fmproto.html
http://www.perl.com/pub/language/misc/bunce.html
--tom
--
Windows 95: n.
32 bit extensions and a graphical shell for a 16 bit patch to an
8 bit operating system originally coded for a 4 bit microprocessor,
written by a 2 bit company, that can't stand 1 bit of competition.
Randal L. Schwartz
Randal> Tom, you still need to remove ($@) from the "useless list" of
Randal> prototypes. It's hardly useless. It requires one scalar parameter,
Randal> but accepts additional parameters in list context. Probably ditto for
Randal> (*@), but I haven't thought that one through carefully enough.
On a more careful reading, *@ doesn't appear. It's %@. Durn stupid
font/size that perl.com Songline folks picked. Just another reason
to hate the new design. :)
Sorry about that.
Randal L. Schwartz
Tom> I think you'll find that these should answer your question:
Tom> http://www.perl.com/pub/language/misc/fmproto.html
Tom, you still need to remove ($@) from the "useless list" of
prototypes. It's hardly useless. It requires one scalar parameter,
but accepts additional parameters in list context. Probably ditto for
(*@), but I haven't thought that one through carefully enough.
I noticed that on first reading... sorry I didn't get around to
telling you yet.
print "Just another Perl hacker,"
Bernie Cosell
} [courtesy cc of this posting mailed to cited author]
}
} In comp.lang.perl.moderated,
} Jay Rogers <j...@rgrs.com> writes:
} :Yes removing &() reduces visual clutter, but it's
} :likely an important clue to some poor maintainer who's not that
} :familiar with the code or Perl's hundred some functions.
}
} Larry intentionally allowed you to remove the ampersand. This is
} the preferred notation in Perl5. ....
Hmm... Perhaps I'm missing something here. The reason I *always* use '&'
before subroutine calls is so that my code doesn't break. I write a lot of
Perl code that basically lurks around in the background and just keeps
runnning, and it is a bit scary that if someone loads a new copy of CGI.pm
and it happens to export one new variable [which we wouldn't have been
using, of course, since it wasn't there when we wrote the code] or we load
a new version of Perl and it has a new keyword... it could cause a lot of
maintenance-headaches...
Am I missing something here: is the real suggestion "always use prototypes
and not '&'" or is there some way of making sure that your program won't
break in six months when someone changes something that has *nothing* to do
with your program ... Toms' example about 'log':
} sub log { return "This is your message: @_\n" }
} print log("skullduggery")
} ^D
} Can't take log of 0 at - line 2.
} [ Exit 255 ]
}
} No problem -- you never make it to run time, boys.
is of course just self-serving: you can hardly *count* on the fact that
your use of a subroutine name and the 'system use' will actually always
save you by generating an error.
And 'you never make it to run time' strikes me as wholly bogus: big deal
that you write code that _might_ make a complaint [then again, it might
just screw up!]. That's still a totally unacceptable result for production
code, IMO. I don't want my code to break in six months, and I certainly
don't want a maintenance programmer to have to guess what went wrong with
something that had been working for a long time, nor do I want my shop to
basically stop working as a pile of programs all stop working. [NB: I know
that you do have to test things and sometimes upgrades *DO* cause problems
[everyone who had an email address in a string and had their program break
when they went to Perl 5 raise their hand..:o)], but it strikes me as
hardly sensible to *promote* a coding style that _invites_ such problems,
rather than finding ways to make perl programs *more* invulnerable...
So I'm not at all convinced that no-& is a good policy for long-life,
bulletproof, production code... but I never use prototypes [weren't there
when I started Perl, and I've never really incorporated them into my
'style']... and so I iterate my inquiry above, since the advice *as*stated*
strikes me as very bad advice: is the actual advice "always use prototypes
and no '&'"?
/Bernie\
--
Bernie Cosell Fantasy Farm Fibers
ber...@fantasyfarm.com Pearisburg, VA
--> Too many people, too few sheep <--
Tom Christiansen
In comp.lang.perl.moderated,
Bernie Cosell <ber...@fantasyfarm.com> writes:
:} Larry intentionally allowed you to remove the ampersand. This is
:} the preferred notation in Perl5. ....
:
:Hmm... Perhaps I'm missing something here. The reason I *always* use '&'
:before subroutine calls is so that my code doesn't break. I write a lot of
:Perl code that basically lurks around in the background and just keeps
:runnning, and it is a bit scary that if someone loads a new copy of CGI.pm
:and it happens to export one new variable [which we wouldn't have been
:using, of course, since it wasn't there when we wrote the code] or we load
:a new version of Perl and it has a new keyword... it could cause a lot of
:maintenance-headaches...
Who ever said that exporting everything willy-nilly was a great idea?
Who ever said that importing everything willy-nilly was a great idea?
Who ever said that *changing the interface* with each release of a module
was a bad idea?
It sounds to me like somebody has been hosing you over, and now you're a
burnt child who fears fire. When you live in a hostile world of mutual
namespace invasion and interface transmogrification, I guess you just
have to do what you do. Sounds like a social problem. Beat on the
module authors who are misbehaving.
Obsequious use of a leading ampersand has its drawbacks, as I have
already explained.
I believe that if you inspect the CORE modules that ship with Perl, this
practice is rare at best. The CORE works very hard to avoid adding any
new keywords, especially those added in a way that would conflict with
user functions. The last time I was bitten by this issue was when pipe()
became a keyword, because that got in the way of writing:
open(pipe, "| lpr");
Guess when that was? :-)
--tom
--
Hi, this is Ken. What's the root password?
Russ Allbery
> Hmm... Perhaps I'm missing something here. The reason I *always* use
> '&' before subroutine calls is so that my code doesn't break. I write a
> lot of Perl code that basically lurks around in the background and just
> keeps runnning, and it is a bit scary that if someone loads a new copy
> of CGI.pm and it happens to export one new variable [which we wouldn't
> have been using, of course, since it wasn't there when we wrote the
> code]
This is the reason why one should always specifically import only those
things you're actually using and never give the module blanket permission
to play with your namespace unless you're writing a fairly short script.
Even then, it's good to get into the habit.
> or we load a new version of Perl and it has a new keyword...
The Perl maintainers are well aware of this problem, and I think matters
would be very dire indeed before they did something to cause serious
problems here. That's the reason why lock is a second-class keyword.
--
#!/usr/bin/perl -- Russ Allbery, Just Another Perl Hacker
$^=q;@!>~|{>krw>yn{u<$$<[~||<Juukn{=,<S~|}<Jwx}qn{<Yn{u<Qjltn{ > 0gFzD gD,
00Fz, 0,,( 0hF 0g)F/=, 0> "L$/GEIFewe{,$/ 0C$~> "@=,m,|,(e 0.), 01,pnn,y{
rw} >;,$0=q,$,,($_=$^)=~y,$/ C-~><@=\n\r,-~$:-u/ #y,d,s,(\$.),$1,gee,print
Bernie Cosell
} [courtesy cc of this posting mailed to cited author]
}
} In comp.lang.perl.moderated,
} Bernie Cosell <ber...@fantasyfarm.com> writes:
} :} Larry intentionally allowed you to remove the ampersand. This is
} :} the preferred notation in Perl5. ....
} :
} :Hmm... Perhaps I'm missing something here. The reason I *always* use '&'
} :before subroutine calls is so that my code doesn't break. I write a lot of
} :Perl code that basically lurks around in the background and just keeps
} :runnning, and it is a bit scary that if someone loads a new copy of CGI.pm
} :and it happens to export one new variable [which we wouldn't have been
} :using, of course, since it wasn't there when we wrote the code] or we load
} :a new version of Perl and it has a new keyword... it could cause a lot of
} :maintenance-headaches...
}
} Who ever said that exporting everything willy-nilly was a great idea?
}
} Who ever said that importing everything willy-nilly was a great idea?
}
} Who ever said that *changing the interface* with each release of a module
} was a bad idea?
No one. But who ever said that no contributor to CPAN ever tweaks
anything?
} It sounds to me like somebody has been hosing you over, and now you're a
} burnt child who fears fire. When you live in a hostile world of mutual
} namespace invasion and interface transmogrification, I guess you just
} have to do what you do. Sounds like a social problem. Beat on the
} module authors who are misbehaving.
Life is too short. When just using '&' makes the problem not ever appear,
it is hard (for me at least) to opt for the rather minimal benefits of
going no-&.
} Obsequious use of a leading ampersand has its drawbacks, as I have
} already explained.
Actually, I missed the drawbacks part, unless it was in another thread.
Your previous article in this thread only listed a few advantages of the
non-&, advantages I found to be hardly earthshattering...
[just for reference, they were:
} } 0) it's easier to read without as much clutter.
} } 1) list operator precedence, just like a built-in (usually)
} } 2) prototype checking, like a built-in (if given)
} } 3) protection from upstack mutilations by those you call
On '0', if you're worried about clutter I'd suggest that instead of messing
with '&' you turn your attentions to that garbage-pit of bad and confusing
syntax, the re-engine-mess. Now *THATS* clutter.
Don't find (1) as much of an advantage, but maybe I'm missing something
real important there.
(2) goes back to my original comment [which was that perhaps the proper
suggestion is not "no &" but "use prototypes AND don't bother with &".
As for three, I can just parrot:
Who ever said it was a good thing to do upstack mutilations at all? Go fix
that lower-level code...
Other than your use of the word 'obsequious' [did you just learn it and so
you're trying to repeat it enough so that it'll "stick"? It is hardly the
right term], you didn't say much about the disadvantages of '&'.
In a world where almost every identifier is preceded by a "what this
identifier means" character [$, \, etc] it seems odd to rail so much about
something that is basically in line with that aspect of the rest of the
language [the kludge, if there is one, is the machinations necessary to get
non-& user functions to work properly [or at least
properly-most-of-the-time, until you get burnt]].
Can't wait for you to start your campaign about the obsequious use of '$'
..., or the campaign to deprecate 'use strict' and so avoid the clutter of
the obsequious use of "use vars qw//".
} I believe that if you inspect the CORE modules that ship with Perl, this
} practice is rare at best. The CORE works very hard to avoid adding any
} new keywords, especially those added in a way that would conflict with
} user functions.
Perhaps. But many of us also use dozens of CPAN modules and modules from
other sources.
} ... The last time I was bitten by this issue was when pipe()
} became a keyword,
You mean you didn't get bitten by '@' in strings? I admit it is not the
same _problem_, but it is the same _issue_. I was NOT a happy camper to
have random programs [many very rarely used, and so it took a while for all
the problems to show up] blow up long after the fact, and to have code from
other sources and other programmers not work [because they were coded for
the previous version, and other than the '@' worked perfectly].
Looks like we're stuck disagreeing...
I guess I remain unconvinced that the drawbacks of '&' are particularly
severe, nor that the advantages of 'non-&' are particularly worthwhile, and
so it comes down, I guess to clutter versus reliability. You believe that
'&' in front a function call is 'clutter', while I think it makes the code
more clear. Conversely, I think that *not* putting the '&' in front of a
call leaves you code open to failing mysteriously in the future, while you
think that such things don't/won't/shouldn't happen.
Tom Christiansen
Bernie Cosell <ber...@fantasyfarm.com> writes, quoting me:
:} Who ever said that exporting everything willy-nilly was a great idea?
:} Who ever said that importing everything willy-nilly was a great idea?
:} Who ever said that *changing the interface* with each release of a module
:} was a bad idea?
:
:No one. But who ever said that no contributor to CPAN ever tweaks
:anything?
That's their fault, not yours.
:Life is too short.
Perhaps Perl isn't the right language for you.
:On '0', if you're worried about clutter I'd suggest that instead of messing
:with '&' you turn your attentions to that garbage-pit of bad and confusing
:syntax, the re-engine-mess. Now *THATS* clutter.
Completely irrelevant. Don't distract from the issue. We're
talking about subroutine calls, not regexes. You could point out
that APL and vi macros are line-noisier, too, but this remains
as diverting as your regex point. Stick to the topic.
Many other languages that use type symbols for variables don't need
them for subroutine or function calls. We're following the principle
of least surprise here in Perl.
:Don't find (1) as much of an advantage, but maybe I'm missing something
:real important there.
It means there's no difference between a built-in function and
a user-defined one. There's something appealing about
print "fred\n";
that
&vprint("fred\n");
completely loses. This allows you to say
vprint "fred\n";
:(2) goes back to my original comment [which was that perhaps the proper
:suggestion is not "no &" but "use prototypes AND don't bother with &".
Content templates have their purposes, but intentionally circumventing
them is highly suspect.
:As for three, I can just parrot:
Parroting is very impressive, but perhaps next time you'd care to try
a modicum reasoning instead.
:Who ever said it was a good thing to do upstack mutilations at all? Go fix
:that lower-level code...
I'm afraid now you've got the polarity reversed. It's *your code* that's
wrong this time. You see, in the case you claimed to be worried about,
you expressed concern that the API might change for some subroutine that
you didn't write. That is, you were worried about something outside
of your world happening to screw you up your world. My advice to this
is that you should probably just go about own business in a respectable
and courteous way, and expect others to do behave likewise.
But now you're talking about something which is completely the opposite.
This time it is *you* and not they who have control over the code
in question, and it is *you* who are risking messing things up. This
is a completely different situation. In the first case, we're talking
about the perils of code you didn't write, in which case there's
really nothing you can do. But in this new case, now you're talking
about perils of code that you *did* write! The cure for this is
clear: don't be a fool.
The code that you didn't write is *not* misbehaving if its API is to
alter its parent caller's argument. It is *you* who choose to trick the
poor thing into upstacking by accident and consequently inadvertently
altering its grandparent caller's argument. On your head be it.
:Other than your use of the word 'obsequious' [did you just learn it and so
:you're trying to repeat it enough so that it'll "stick"? It is hardly the
:right term],
Great, first you try to distact by not arguing the question, and now
you come remarkably close to a classic ad hominem argument. Sigh.
For the record, here are two dictionary definitions for the word.
Please study them.
* Compliant with the will or wishes of another, esp. of a superior;
prompt to serve, please, or follow directions; obedient; dutiful.
* Unduly or servilely compliant; ignobly submissive; manifesting or
characterized by servile complaisance; fawning, cringing, sycophantic.
I meant what I said, and I said what I meant: the urge to mindlessly
stick an ampersand all over the place is as sycophantically dutiful as
are CS101 students' classic /* add one to i */ comments. It's certainly
a shame that you were unfamiliar with the intended usage and meaning,
but I trust that this has been cleared up now.
:you didn't say much about the disadvantages of '&'.
Points 0 through 3 certainly did. I suppose I could add "it makes
one look as though one were six years behind the times".
:In a world where almost every identifier is preceded by a "what this
:identifier means" character [$, \, etc] it seems odd to rail so much about
:something that is basically in line with that aspect of the rest of the
:language
Every identifier? I think not. In fact, it sure looks like
they're in the minority.
open(FH, $pathspec)
^^ There's an identifier there. What's its symbol?
while (<FH>)
^^ There's an identifier there. What's its symbol?
@oldbuff = stat(_)
^ There's an identifier there. What's its symbol?
TOP: while (1)
^^^ There's an identifier there. What's its symbol?
@f = readdir(DIRH);
^^^^ There's an identifier there. What's its symbol?
package Fred;
^^^^ There's an identifier there. What's its symbol?
goto Jump_Start;
^^^^^^^^^^ There's an identifier there. What's its symbol?
setpwent();
^^^^^^^^ There's an identifier there. What's its symbol?
format End_Page =
^^^^^^^^ There's an identifier there. What's its symbol?
use Curses;
^^^^^^ There's an identifier there. What's its symbol?
$x = $h{verb} # see note 1
^^^^ There's an identifier there. What's its symbol?
$n = CGI->new();
^^^ There's an identifier there. What's its symbol?
Foo::Bar::glarch()
^^^ There's an identifier there. What's its symbol?
^^^ There's yet another identifier there. (note 2)
$line = <<SOMETAG . fn(); # see note 3
^^^^^^^ There's an identifier there. What's its symbol?
uc($a) cmp uc($b)
^^^ There's an identifier there. What's its symbol?
fn(-TIME => time()); # see note 4
^^^^ There's an identifier there. What's its symbol?
=head1 DESCRIPTION # see note 5
^^^^^ There's an identifier there. What's its symbol?
Note 1: perldata
In fact, an identifier within such curlies is forced to be a
string, as is any single identifier within a hash subscript.
Our earlier example,
$days{'Feb'}
can be written as
$days{Feb}
and the quotes will be assumed automatically. But anything more
Note 2: perldata
Most often, it consists of a single identifier, that is, a string
beginning with a letter or underscore, and containing letters,
underscores, and digits. In some cases, it may be a chain of
identifiers, separated by :: (or by ', but that's deprecated); all
but the last are interpreted as names of packages, to locate the
namespace in which to look up the final identifier (see the Packages
entry in the perlmod manpage for details)
Note 3: perldata
The terminating string may be either an identifier (a word), or
some quoted text. If quoted, the type of quotes you use determines
the treatment of the text, just as in regular quoting. An unquoted
identifier works like double quotes. There must be no space between
the << and the identifier.
Note 4:
Unary "-" performs arithmetic negation if the operand is numeric.
If the operand is an identifier, a string consisting of a minus
sign concatenated with the identifier is returned. Otherwise,
if the string starts with a plus or minus, a string starting with
the opposite sign is returned. One effect of these rules is that
-bareword is equivalent to "-bareword".
Note 5:
All command paragraphs start with "=", followed by an identifier,
followed by arbitrary text that the command can use however it pleases.
[the kludge, if there is one, is the machinations necessary to get
:non-& user functions to work properly [or at least
:properly-most-of-the-time, until you get burnt]].
I see no kludge.
:Can't wait for you to start your campaign about the obsequious use of '$'
:..., or the campaign to deprecate 'use strict' and so avoid the clutter of
:the obsequious use of "use vars qw//".
And your point, sir, is precisely what? That you're once again attempting
to distract from the question? Sorry, but I'd rather not fall for such
a cheap ploy. Stick to the matter at hand.
:} ... The last time I was bitten by this issue was when pipe()
:} became a keyword,
:
:You mean you didn't get bitten by '@' in strings? I admit it is not the
:same _problem_, but it is the same _issue_.
The issue being what, that incompatibilities can occur across upgrades?
And this is news? I think not. You're certainly welcome to continue
to run perl4. And with all those &fn() calls, no one will be able to
tell the difference.
The Perl CORE goes to a remarkable amount of trouble in order to avoid
breaking old programs. I do not think it is us whom you should be
laying the blame upon in this matter. Everytime you say
use Module;
or
use Module ':DEFAULT';
rather than
use Module ();
or
use Module qw/some list here/;
It is you yourself who are asking for trouble. I agree that modules that
escalate their namespace invasions across releases are questionable,
but there's enough blame here to go around and come back to you for
just begging to be abused.
In Chapter 5 of the Camel, Larry wrote:
The module and its user have a contract, part of which is common
law and part of which is "written". Part of the common law contract
is that a module doesn't pollute any namespace it wasn't asked to.
The written contract for the module (that is, the documentation) may
make other provisions. But then having read the written contract,
you presumably know that when you say:
use RedefineTheWorld;
you're redefining the world, and you're willing to take the
consequences. The next section talks about one way to redefine
parts of the world.
When that happens, you have no right to complain that someone took you
up on the offer.
>Looks like we're stuck disagreeing...
Congratulations, you've now wasted more than enough of my time already.
This note was written for the benefit of other readers, since you have
already stated that you weren't going to stop disagreeing. I hope you
realize why, given your stated position and your flamish argumentative
"techniques", that you now find yourself consigned to my own private
blackhole of peace known as a killfile. I have no time for people who
not only intend to remain stuck in their position (perl4ish as it is),
but who also resort to ad-hominem attacks and petty strawmen.
--tom
--
Only God can make random selections.
Bernie Cosell
} Bernie Cosell <ber...@fantasyfarm.com> writes:
}
} > Hmm... Perhaps I'm missing something here. The reason I *always* use
} > '&' before subroutine calls is so that my code doesn't break. I write a
} > lot of Perl code that basically lurks around in the background and just
} > keeps runnning, and it is a bit scary that if someone loads a new copy
} > of CGI.pm and it happens to export one new variable [which we wouldn't
} > have been using, of course, since it wasn't there when we wrote the
} > code]
}
} This is the reason why one should always specifically import only those
} things you're actually using and never give the module blanket permission
} to play with your namespace unless you're writing a fairly short script.
} Even then, it's good to get into the habit.
I agree. It took going a LONG way through Tom's note to get to this point.
[the other advantages he bangs on don't really strike me as particular
salient for 'general programming' --- if you're not trying to write a new
routine that is pretending to be built-in or doing wield stack hackery or
the like, & or non-& isn't such a big issue].
This is really the heart of the matter and as careful a programmer as I try
to be [and rant and rave about 'robustness'] I admit that this is an
*AWFUL* habit (and one that I have now just banished from my repertoire!!
I"m even going to start doing "use integer ()" just to make sure..:o))
So I'm convinced, and being convinced of *THAT*, makes the use of '&' a LOT
less compelling. You still might need it once in a while [sub log {...} ],
but I admit that it does *NOT* introduce any real problems into code [that
didn't already have them elsewhere..:o)] and so I think I concede.
} > or we load a new version of Perl and it has a new keyword...
}
} The Perl maintainers are well aware of this problem, and I think matters
} would be very dire indeed before they did something to cause serious
} problems here. That's the reason why lock is a second-class keyword.
I appreciate this, and if I said something that implied that I thought that
the base Perl reserved-word set was tinkered with idly, I apologize since
nonesuch was intended. My real problem, as you homed right in on, was with
my poor programming practice ["willy-nilly" importing]... and my patching
around it [with '&'s] rather than fixing it [with explicit imports].
But you've piqued my interest: what is a second-class keyword?
And I just grepped through all of the perl man pages here [5.004_004] and I
can't find any mention of 'lock'... what is it? [probably something in a
later version of Perl, I'm guessing]