implementation of file-related modules

[Isaac Jones]

Alastair Reid <alastair at reid-consulting-uk.ltd.uk> writes:

> In favour of the configuration file approach, there's the potential for 
> shipping portable bytecode files from one platform to another and it can 
> probably be tweaked to support multiple platforms at once by providing a 
> 'Configuration' abstract data type.

I was thinking about this a little more, and I came up with a small
argument against it (or at least part of it):

For something like path separators, it seems fine to have
Directory.Windows, Directory.Unix, and Directory.Mac, then have
Directory.Native bind at compile time.

But for something like "configuration file directory", which might be
"/etc" on Debian, "/usr/local/etc" on FreeBSD, a wide variety of
things on various windows configurations (at least for user
configuration files, not sure about system config files), and
"/Library/Preferences" on MacOS X, this solution starts to look a
little uglier since it requires a module for each platform, which
somewhat randomly pollutes the namespace for something like Directory.
It's even worse if you assume that we'll run into other modules where
this matters.

What if we had a module for platform-specific things and submodules
for each platform.  This would keep all of the platform-specific
details localized and easier to maintain.  So perhaps we could have

Platform.{Debian,FreeBSD,MacOSX,Windows98,Windows2000}.{configDirectory,fileSeparator,etc}

or:

Platform.{Debian,FreeBSD,MacOSX,Windows98,Windows2000}.Directory.{configDirectory,fileSeparator,etc}

and

Platform.Native.{configDirectory,fileSeparator,etc}

or

Platform.Directory.{configDirectory,fileSeparator,etc}

which is bound as above.

But that sorta stinks because fileSeparator probably belongs in the
Directory module.  I say that's OK; we can still have:
Directory.fileSeparator = Platform.Native.fileSeparator

So this still lets you get to the platform specific stuff, but doesn't
clutter up random parts of the module hierarchy with platform-specific
modules.  It lets you treat Directory.fileSeparator in a very natural
way for most uses.

Opinions?

peace,

isaac