SpanMode uses incorrect terminology (breadth)

Ben Davis entheh at cantab.net
Tue Sep 18 13:08:39 PDT 2012


On 18/09/2012 15:25, David Piepgrass wrote:
>> Breadth-first (probably never required):
>> a/b
>> a/c
>> a/1.txt
>> a/2.txt
>> a/b/1.txt
>> a/b/2.txt
>> a/c/z
>> a/c/1.txt
>> a/c/z/1.txt
>> Defining property: number of /'s increases monotonically. Note how the
>> deeper you go, the more spread out the children become. It's ALL
>> children, then ALL grandchildren, then ALL great-grandchildren, etc.
>>
>> I wouldn't bother implementing breadth-first. It's doubtful that
>> anyone would want it, surely...?
>
> Actually I prefer breadth-first search when searching the file system.
> When I search an entire volume, inevitably the (depth-first) search gets
> stuck in a few giant, deep directories like the source code of Mono or
> some other cave of source code, you know, something 12 directories deep
> with 100,000 files in it. A breadth-first search would be more likely to
> find the thing I'm looking for BEFORE going spelunking in these 12-deep
> caves.

Fair point. :)

So there is a case for implementing breadth-first iteration (or as 
Mehrdad suggests, iterative deepening - it's just a CPU-memory 
tradeoff). However, the currently implemented 'breadth' (preorder 
depth-first) is probably used a lot, and someone might be relying on its 
current behaviour (e.g. to create a tree view). So how do we proceed 
without silently breaking existing code? Do we use 'breadthFirst' 
instead of 'breadth'? Do we just gulp and change it? Do we rename 
'SpanMode' to 'TreeMode' or something?


More information about the Digitalmars-d mailing list