On 2011-06-10 05:22, Dmitry Olshansky wrote:
> On 10.06.2011 16:19, Andrei Alexandrescu wrote:
> > On 6/10/11 4:47 AM, Jonathan M Davis wrote:
> >> The main problem with dirEntries is essentially as you point out. It
> >> doesn't
> >> work with anything but foreach. You can't even pass it to
> >> std.array.array to
> >> create an array. And it's because it's set up to work with either a
> >> string or
> >> a DirEntry for the loop variable. The advantage of listdir/listDir is
> >> that you
> >> get an actual array of strings to use when you need to pass it to
> >> something.
> >> Ideally, DirIterator wolud be made to work with more, but it hasn't
> >> been. I
> >> don't know if we want to try and turn it into a range or what, but it
> >> is a bit
> >> of a problem if you want to use dirEntries outside of a foreach loop.
> > 
> > Any chance of somebody finding the time to transform dirEntries into an input range? That would solve everything.
> 
> I decided to try just that. It will take some time though.

The only thing that I can think of doing is making it so that DirIterator is a range with element type DirEntry and make DirEntry have an alias this to its name property. I _think_ that that will give the same behavior as the current behavior. Certainly, I don't know how else we'd do it. The ability to have multiple iteration types for the same range is not exactly one of ranges strong points.

Feel free to rearrange DirIterator and _listDir's internals as long as it doesn't break the current good behavior (that is, how dirEntries works with foreach and how listdir/listDir works, though listdir/listDir can have a separate implemnetation if need be, since it's going away). And if you're actually going to end up messing with the internals rather than just changing DirIterator's API, then keep this bug in mind: http://d.puremagic.com/issues/show_bug.cgi?id=6138 (currently, calling chdir in the middle of iterating with dirEntries causes problems). I'm not sure whether the current behavior is what we want or not, since it's a bit like modifying a collection or range while iterating over it, and that's not necessarily something that you can expect to work. But if it's an easy fix to make it work, then that's what we probably want. If you're just messing with DirIterator's API rather than how it works internally though, then don't worry about it. We can sort out 6138 later.

- Jonathan M Davis

On 2011-06-10 09:21, Jonathan M Davis wrote:
> On 2011-06-10 05:22, Dmitry Olshansky wrote:
> > On 10.06.2011 16:19, Andrei Alexandrescu wrote:
> > > On 6/10/11 4:47 AM, Jonathan M Davis wrote:
> > >> The main problem with dirEntries is essentially as you point out. It
> > >> doesn't
> > >> work with anything but foreach. You can't even pass it to
> > >> std.array.array to
> > >> create an array. And it's because it's set up to work with either a
> > >> string or
> > >> a DirEntry for the loop variable. The advantage of listdir/listDir is
> > >> that you
> > >> get an actual array of strings to use when you need to pass it to
> > >> something.
> > >> Ideally, DirIterator wolud be made to work with more, but it hasn't
> > >> been. I
> > >> don't know if we want to try and turn it into a range or what, but it
> > >> is a bit
> > >> of a problem if you want to use dirEntries outside of a foreach loop.
> > > 
> > > Any chance of somebody finding the time to transform dirEntries into an input range? That would solve everything.
> > 
> > I decided to try just that. It will take some time though.
> 
> The only thing that I can think of doing is making it so that DirIterator is a range with element type DirEntry and make DirEntry have an alias this to its name property. I _think_ that that will give the same behavior as the current behavior. Certainly, I don't know how else we'd do it. The ability to have multiple iteration types for the same range is not exactly one of ranges strong points.

The more I think about it, the more I think that this is the correct solution. I just don't see any other way to do it. And it should actually be pretty easy to do. The main question is whether we want to mess with DirIterator's internals with regards to _listDir and its delegate solution. And that's completely up to you, but I think that I'd be inclined to leave it alone for the moment (probably until listdir and listDir are gone), since it's fewer changes and fewer places to introduce bugs.

- Jonathan M Davis

On 10.06.2011 23:04, Jonathan M Davis wrote:
> On 2011-06-10 09:21, Jonathan M Davis wrote:
>> On 2011-06-10 05:22, Dmitry Olshansky wrote:
>>> On 10.06.2011 16:19, Andrei Alexandrescu wrote:
>>>> On 6/10/11 4:47 AM, Jonathan M Davis wrote:
>>>>> The main problem with dirEntries is essentially as you point out. It
>>>>> doesn't
>>>>> work with anything but foreach. You can't even pass it to
>>>>> std.array.array to
>>>>> create an array. And it's because it's set up to work with either a
>>>>> string or
>>>>> a DirEntry for the loop variable. The advantage of listdir/listDir is
>>>>> that you
>>>>> get an actual array of strings to use when you need to pass it to
>>>>> something.
>>>>> Ideally, DirIterator wolud be made to work with more, but it hasn't
>>>>> been. I
>>>>> don't know if we want to try and turn it into a range or what, but it
>>>>> is a bit
>>>>> of a problem if you want to use dirEntries outside of a foreach loop.
>>>> Any chance of somebody finding the time to transform dirEntries into an input range? That would solve everything.
>>> I decided to try just that. It will take some time though.
>> The only thing that I can think of doing is making it so that DirIterator is a range with element type DirEntry and make DirEntry have an alias this to its name property. I _think_ that that will give the same behavior as the current behavior. Certainly, I don't know how else we'd do it. The ability to have multiple iteration types for the same range is not exactly one of ranges strong points.
> The more I think about it, the more I think that this is the correct solution. I just don't see any other way to do it. And it should actually be pretty easy to do. The main question is whether we want to mess with DirIterator's internals with regards to _listDir and its delegate solution. And that's completely up to you, but I think that I'd be inclined to leave it alone for the moment (probably until listdir and listDir are gone), since it's fewer changes and fewer places to introduce bugs.
>
> - Jonathan M Davis
For now I going this route, namely, reconstructing DirIterator as an
input range, leaving all listDir functionality as is.
As a bonus dirEntries won't overflow stack because of recursion (thought
admittedly it's a corner case).
And yes, I see no other way then to add  alias this to DirEntry, to make
this change compatible with current API.

-- 
Dmitry Olshansky