http://d.puremagic.com/issues/show_bug.cgi?id=8680
--- Comment #4 from ent...@cantab.net 2012-09-18 09:51:31 PDT --- (In reply to comment #3) > Looks like you are still correct. I'm still looking at the desire for useful > traversal of a filesystem. OK, let's explore that: > I do not see sorting as a solution. I really do not care if the dir is before > the file. What is useful is recieving all children before traversing children. Are you saying you want a real breadth-first search to be implemented? Fine, we can do that, if it's useful. Note though that it'll intersperse children, e.g. a a/1 a/2 a/1/A a/1/B a/2/A a/2/B a/1/A/... a/1/B/... a/2/A/... a/2/B/... a/1/A/.../... etc. - so directories 1 and 2 become increasingly interleaved. > I usually end up ignoring directories anyway. So I'm thinking your origional > suggestion for childrenFirst and parentFirst is actuall what is useful and > does > not need too abide by actual traversal rules, only usefulness. I intended those as alternative names instead of 'postorder' and 'preorder' (respectively) - I didn't intend to suggest any other behaviour. What behaviour do you want? Do you want all of the first-level files and directories (as if starting a breadth-first), followed by all subsequent levels in depth-first order? See I would argue that that's very specific, not intuitive in the general case, and best implemented using two separate calls to the function with different arguments: auto firstLevel = dirEntries("a", SpanMode.shallow); foreach (file; firstLevel) { if (file.isDir()) { ... = dirEntries(file, SpanMode.preorder); } } Or do you want something else? I think this needs clarifying, since there's obviously a misunderstanding in our interpretation of "parentFirst", and "usefulness" is a goal, not a spec. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------