indeed! obvious idea,
the only thing I do not like with it is making these hidden, deceptive decisions "I said I want MMapDirectory and someone else decided something else for me"... it does not matter if we have conses here now, it may change tomorrow
probably better way would be to turbo charge FileSwitchDirectory with sexy parametrization options,
MMapDirectory <- F(fileExtension, minSize, maxSize) // If <fileExtension> and file size less than <maxSize> and greater than <minSize> than open file with MMapDirectory... than go on on next rule... (can be designed upside down as well... changes nothing in idea)
the same for RAMDir, NIO, FS...
With this, we can make UwesBestOfMMapDirectoryFor32BitOSs (your proposal here) or
HighlyConcurentForWindows64WithTermDictionaryInRamAndStoredFieldsOnDiskDirectory just for me
So the most of the end users take some smart defaults we provide in core, and freaks (Expert users in official lingo have their job easy, just to configure TurboChargedFileSwitchDirectory
Should be easy to come up with clean design for these "Concrete Directory selection rules" by keeping concrete Directories "pure"