From: Joel VanderWerf <vjoel@...>
Date: 2005-07-28T07:55:52+09:00
Subject: Re: Dir.entries returns [] on the second call

Mark Hubbart wrote:
> On 7/26/05, Joel VanderWerf <vjoel@path.berkeley.edu> wrote:
> 
>>Yukihiro Matsumoto wrote:
>>
>>>Hi,
>>>
>>>In message "Re: Dir.entries returns [] on the second call"
>>>    on Wed, 27 Jul 2005 07:45:02 +0900, Joel VanderWerf <vjoel@path.berkeley.edu> writes:
>>>
>>>|Stefan Lang wrote:
>>>|> Call <tt>dir.rewind</tt> before <tt>dir.entries</tt> and it
>>>|> works as expected.
>>>|
>>>|Thanks! I knew there was a reasonable explanation.
>>>
>>>Maybe reasonable.  But still not intuitive.
>>>
>>>How about rewinding before "each" method, that make "entries" (and
>>>other iterating methods) require no rewind?
>>>
>>>                                                      matz.
>>
>>I dunno. Shouldn't Dir#each behave like File#each? Would it make sense
>>for File#each to rewind? That seems a pretty radical change.
> 
> 
> I think File#each inherits that behavior from IO, which Dir doesn't
> inherit from. IO's might not be rewindable, but their behavior should
> be mostly interchangeable.
> 
> Dir.each, to me, seems more like a range or array-related method than
> an IO related method; if it is, it perhaps should rewind before #each
> use.

The analogy I think of is: Dir is to opendir(), readdir() as File is to
open(), read().

Dir is like File in other ways. There is a fd involved, there is
Dir#seek, etc.

OTOH, I will probably make this same mistake again (and again...). It
might be better if FileList (or something like it) were part of the core.