Matt Reynolds wrote:
Directory is currently an abstract class that claims in its javadoc that
"Directory is a flat list of files", then goes on to describe non-"flat
list of files" based implementations (JDBC, RAM, etc). Is it worthwhile
to split out Directory into a top level interface, and possibly have the
existing abstract class be a FileBaseDirectory instead?
Directory provides a file abstraction. That abstraction may be
implemented in various ways, for example, as a disk-based filesystem,
with memory-resident datastructures, in a database, etc. Regardless of
how it is implemented, the abstraction refers to the storage units as
"files", even if they're implemented in memory or a database.
My primary
consideration (since I'm new to the code) is the number of references to
methods like "fileExist" on directory, and their usage of those methods.
They look like they won't work with non-file-based Directories (like
DocumentsWriter?). Is that true? Pointers? Tips? :)
These methods work with all Directory implementations. (Also, BTW,
DocumentsWriter is not a Directory implementation, but a primary
consumer of Directory implementations. An index lives in a Directory.)
Doug
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
