[prev] [thread] [next] [lurker] [Date index for 2006/12/22]
On 12/22/06, Peter da Silva <peter@xxxxxxx.xxx> 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/"There's stuff above here
Generated at 14:01 on 28 Dec 2006 by mariachi 0.52