WC -Sx- Jones wrote:
> # just predeclare them ALL here; before they are used.
> # See my comments below
What I see here are not declarations, but calls. They need no extra decoration, unless
you have a passion for dispensing with parentheses. I like parentheses, for my art. I
think they can help clarify what goes with what.
>
> > ...
> >
> >
> >>&print_if_Warn if (system("nstat -a") / 256);
> >>
> >>&print_if_Fatal if (system("netstat -nr") / 256);
Works fine as:
print_if_Warn() if (system("nstat -a") / 256);
print_if_Fatal() if (system("netstat -nr") / 256);
> > Hi Bill,
> >
> > I'm a little unclear here. What do you see as calling for the ampersand & in the
> > function calls above. Most list veterans have been trying to steer newbies away
> > from it. Have you tried the calls above without?
> >
> > Joseph
> >
> >
> >
>
> sub print_if_Warn;
> sub print_if_Fatal;
>
> That way you can call them without the & later.
> IMHO it makes C programmers out of Perl programmers.
> (And it is MORE lines - but I won't argue with progress :)
So what is the pressing need to eliminate parrentheses? For not only C programmers,
but for people familiar with a whole range of C-based languages, parentheses make very
clear the context in which an identifier is being used. I can apprediate that there
are contexts in which it is nice to dispense with them. When I did some C programming
recently, I actually found myself getting annoyed at having to put parentheses around
the arguments of printf(). For the most part, though, I see parens as the least
distracting of operators.
Joseph
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>
