Peter Scott wrote:
>
> Some people have already suggested renaming them; RFC 30
> takes the obvious step of making $STDIN, $STDOUT, $STDERR but sidesteps the
> issue of $ARGV which already has a meaning :-( If we can solve that one
> then I'd just make all those filehandles scalars.
I've been thinking about this all night, and then it dawned on me that
this isn't actually a problem at all. According to RFC 14, all
fileobjects will have a ->filename attribute, and moreover this
->filename attribute will also be ->STRING, meaning that a fileobject
will morph into the filename it was opened on when in a string context.
This means that $ARGV will be both the filehandle *and* the name of the
file, depending on context:
while (<$ARGV>) { # used as fileobject
next if ($ARGV eq $lastfile) # ->STRING, both are filenames
print "Now reading $ARGV"; # $ARGV->STRING, filename
dostuff($_);
$lastfile = $ARGV; # copies object, but that's ok
#$lastfile = "$ARGV"; # speed-concerned folks could do
this
}
A glimpse of how polymorphic objects can be used practically,
methinks...
I don't think this needs an RFC of its own (just counted, I'm up to 23
RFCs and 2 sublists, so a little overworked :), but if everyone is in
agreement, I'll add it to the bottom of RFC 30 as a "By the way...".
-Nate
P.S. Further discussion should really be on -io, so if you reply please
change the sublist. Thanks.
