>>  That's what I thought I remember from briefly looking at it before,
>> that the way it did that created lots of garbage.  I hope I'm wrong.
>> IMO, FileSystem should be at least equal to FileDirectory across the
>> board, so we leave no reasons at all for someone to want to have
>> FileDirectory in their image (which means they'd have to have both).
>
> I don't think you can expect a general API that's designed for flexibility
> and usefulness across a broad range of applications to perform as well as an
> optimized implementation   that you hand-tuned for your specific
> application. In fact, I'd argue that #directoryTreeDo: shouldn't be part of
> the trunk, it should be an extension method in Banyan.

Colin, may we please not be at odds here?  I'm on your side.

Before you said "Sure, FileSystem does that too" but above you're
saying this method should not be in trunk?  But it should be in trunk
as part of FileSystem?  I'm confused.

> Look at it this way: FileDirectory was missing a lot of features that you
> needed.  Instead of using Filesystem, which provides those features, you
> added them to FileDirectory in a way that's highly specific to the needs of
> your application.

"A lot of features?"  What are you talking about?

I've presented just one short public method (with one supporting
private) from 2007, long before FileSystem, which performs a /very
general/ operation, an efficient internal Iterator of a directory
tree.

> Now you're worried that Filesystem isn't "equal" to
> FileDirectory, meaning that it's not tuned for your application. But if you
> put the same effort into optimizing Banyan+Filesystem, you'd be fine.
> If you don't want to put in that effort, that's fine too. FileDirectory will
> be a loadable package, so you can just make Banyan depend on it, and add it
> to your build script.

I don't understand this defensiveness.  I'm trying to open up to
FileSystem by asking you if this one important function can be made to
perform well as in FD.

I figured you'd look at it and, based on your FS knowledge, say "yes,
an equivalent method could be spanked out in under 5 minutes" (even if
the "efficient" version had to be an extension), so we could be off to
the races.  Is it not the case?  I was hoping to be encouraged by your
reply but surprised instead to hear back that I should lower my
expectations about performance and appreciate the flexibility..?  How
can someone be expected to allocate time to convert legacy code if
it's known certain functions will end up compromised on performance?