Uri Guttman wrote:
>>>>> "JL" == Jonathan Lang <[EMAIL PROTECTED]> writes:
JL> Please. I've always found the "opendir ... readdir ... closedir" set
JL> to be clunky.
JL> Also: why distinguish between "open" and "opendir"? If the string is
JL> the name of a file, 'open' means "open the file"; if it is the name of
JL> a directory, 'open' means "open the directory". If it's the name of a
JL> pipe, it opens the pipe. And so on.
maybe this won't help you but if you did open on a dir in perl5 you can
read the raw directory data which is pretty useless in most cases. so
with open working as opendir on directories, what is the op/method to
get the next directory entry? that isn't the same as reading a
line. there won't be any trailing newlines to chomp. marking a location
is not the same with tell and telldir (one is a byte offset, the other a
directory entry index). and since dirs can reorder their entries
(especially hash based dirs) the ordering and seek points may move. not
gonna happen on text files. there are many differences and the only one
you seem to see is a linear scan of them (which is just the most common
access style).
Well, I did suggest that "openfile" and "opendir" exist alongside
"open", with "openfile" being more akin to Perl 5's "open" or
"sysopen", and "open" being a bit more dwimmy.
But in general, most of the differences that you mention are things
that ought to be addressed in the resulting iterators, not in the
creating statement. No, a "directory handle" will not behave exactly
like a "file handle". But then, a file handle doesn't behave exactly
like "standard in" or "standard out", either (last I checked, Perl 5
won't do anything useful if you say "seek STDIN, 0, SEEK_END").
--
Jonathan "Dataweaver" Lang
