On 12/22/06, Peter da Silva <[email protected]> wrote:
> You know, in Perl, the equivalent of the C snippet would just be:
>
> do_some_process;
>
> while in do_some_process, you'd use the '<>' to read input. Perl has
> the
> snippet build in - if there are no arguments, '<>' will read from the
> file(s) given as arguments.
Yep, Perl is full of rigidly defined areas of doubt and uncertainty
like that. The fix to pointlessly obscure syntax is to introduce more
obscure syntax that handles some common cases that the pointlessly
obscure syntax makes difficult... without actually doing anything about
the fact that you have to use
do_some_process(STDIN);
but
do_some_process(*INPUT);
when you suddenly realize that you need to handle files ending with
".o" differently from files ending in ".a" and by the way doesn't that
mean that file boundaries actually matter now...?
Whats really hateful is complaining about syntax that is more or less
/already deprecated/.
Ok, STDIN, STDOUT, and STDERR are exceptions, but in general one does
not use globally scoped file handles in perl. Instead one is strongly
recommended to use lexically scoped filehandles, which dont have any
of the issues that you have outlined.
And frankly you can always
my $stdin = \*STDIN;
my $stdout = \*STDOUT;
my $stderr = \*STDERR;
...
do_some_process($stderr);
instead. Or just think to yourself "STDIN, STDOUT, STDERR are not like
the other filehandles my program might deal with, as they are provided
by the shell/os, so maybe they /should/ look different"
Cheers,
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
