<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, May 27, 2013 at 2:45 PM, Chris Muller <span dir="ltr">&lt;<a href="mailto:ma.chris.m@gmail.com" target="_blank">ma.chris.m@gmail.com</a>&gt;</span> wrote:<br>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"> Colin, may we please not be at odds here?  I&#39;m on your side.</div>
</blockquote></div><br></div><div class="gmail_extra" style>I&#39;m sorry, I didn&#39;t mean for that post to be so confrontational. I misread your post as shifting the goal-posts so that FileSystem wouldn&#39;t be acceptable unless it performs like your tuned-for-Banyan additions to FileDirectory. </div>
<div class="gmail_extra" style><br></div><div class="gmail_extra" style>There&#39;s certainly room to optimize the tree-walking code in Filesystem, so we may be able to meet your needs that way. </div><div class="gmail_extra" style>
<br></div><div class="gmail_extra" style>On the other hand, there are layers of indirection in Filesystem that aren&#39;t present in FileDirectory. Filesystem works with many kinds of directory trees—on disk, in-memory, inside a zip file, inside a git repository etc. It also has whole-tree operations that need to be able to customize the tree walking algorithm. For example, copying a tree needs to visit directories before their contents, while deleting a tree needs to visit directories after their contents. So from the point of view of Filesystem, #directoryTreeDo: is *not* a very general operation, it&#39;s quite specific, and tuned for a particular use-case. It may not be possible to optimize Filesystem&#39;s tree-walking code to the same level of memory efficiency without sacrificing generality. </div>
<div class="gmail_extra" style><br></div><div class="gmail_extra" style>But that&#39;s not a show-stopper! We could make a method like #directoryTreeDo: just for Banyan, or Banyan could keep on using FileDirectory. It&#39;s not like FileDirectory would be removed in 4.5, and even when it finally does get removed, it would still be available as a compatibility package. </div>
<div class="gmail_extra" style><br></div><div class="gmail_extra" style>Again, my apologies for the over-reaction.</div><div class="gmail_extra" style><br></div><div class="gmail_extra" style>Colin</div></div>