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?
