> In a recursive search, does the pattern glob apply to the whole > path or just the last element (e.g. filename)?
I think the answer here is "to do what other globs do" but I haven't used them enough to know myself (and apologize for my ignorance so far which I'm not correcting here in order to get a timely response back to you). By intuition, I'd say: * Clearly, you'd want "*.txt" in recursive mode to match any *.txt in a directory hierarchy implying that either it only applies to the final element (or that the "*" matches against the path in addition to the file base, though that sounds worse to me). * On the other hand, if you used "a.txt" as the pattern in recursive mode, you'd like it to find all "a.txt"s anywhere and wouldn't want to have to do "*/a.txt" (I think?). * On the third hand, if you did ".svn/entries" as your glob in recursive mode, you'd like it to match part of the path and the file as well. So maybe everything up to the final slash (if there is one) serves as a glob for directories to search and then the stuff after the slash serves as a glob for things to yield (?). At one point we also wondered whether we needed two globs -- one for which subdirectories to search and one for which things to yield -- but that seems unnecessarily picky to me, if we can avoid it. > When dotfiles=true, does it go through '..' and '.' directories > (so that a recursive list loops infinitely?) I hope not. My thinking is that we'll always special-case and skip these two. > It might be interesting to support a regular expression on the path in > addition to globbing... See above. > Could you create a version that ran a user function in order > to decide whether or not to return a file or descend when recursing? > Or that sets a variable shared by the iterator to indicate if > something should be returned? To my thinking, if one wanted to do this, they'd want to use this iterator in non-recursive mode and control the recursive step themselves. I think that this would be preferable to complicating the interface (and not too complex for the user). > I think that this interface is maybe more complicated than it needs to > be -- perhaps the filtering could be accomplished with a user function > and some nice default functions and so you wouldn't need so many options > (for dotfile, pattern, files, dirs). I think these things could be moved into a more general filter capability, but this goes back to my comment on the SCM filtering options on things like find. As a user, I think there are common cases that are commmon enough that I'd rather flip a boolean than require me to write a filter myself. My thinking is that writing a filter is a barrier to use (at least until the language has great support for anonymous lambda expressions or something like that. > Lastly, I think 'find' is a reasonable name for this. Noted. -Brad ------------------------------------------------------------------------------ Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk _______________________________________________ Chapel-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-users
