[ANN] Directory 1.0 released

[Martin Wierich]

Hoi Erik,

Thanks for your mail. In my opinion a library should be both as general and as
primitive as possible. The designer of a library always has the problem that
it's not known how this library is going to be used. In the case of the
Directory library there will be users that are happy that their program runs in
the same way on every platform and there will be other users who don't care
about other platforms than their own but who insist in having all features
available that are offered by their operating system, e.g. Unix access rights or
Mac file types. So I have chosen to offer the platform dependent features to the
application programmer but also to seperate them from the platform independent
part. That's why the FileInfo type contains the two fields pi_fileInfo and
pd_fileInfo ("pi" for "platform independent", "pd" for "platform dependent").

> 1)      Put platform-dependent stuff in separate modules per platform. That
> would give you four modules:
> Directory, DirectoryMac, DirectoryWin en DirectoryUNIX. Then if a
> system-controler would want to check if an application is completely
> platform-independent, (s)he would only have to check the import statements,

Not a bad idea. With the current implementation the system-controler had to
check, whether the record field "pd_fileInfo" appears in the source code.
Seperating this on a module level makes things more clearly.

> 2)      Simply kick out the platform-dependent stuff. So what about
> winLastAccessTime? It is nice that Windows has it, but apparently other
> vendors saw no reason to support it, so it may not be that important.

I think that there sometimes will be the case where the platform dependent
features are needed, especially if you think about commercial applications.

>
> 3)      Put all platform-dependent record-fields together in ONE BIG
> file-info-record. That gives the fields: fileName, fileSize, lastModified,
> isDirectory, isReadOnly, unixModeBitsField, unixOwnerUserId,
> unixOwnerGroupId, unixLastAccessTime, winCreationTime, winLastAccessTime,
> winDOSName, winIsHidden, winIsArchiveFile, winIsSystemFile, macCreationTime,
> macBackupTime, macIsHidden, macFDFlags, macFurtherInfo. Then unify similar
> fields (so winCreationTime and macCreationTime together become creationTime,
> etc.) and make sure that unsupported fields get an undef value or some
> harmless default value, so on the mac the field unixModeBitsField could be
> undef, or all bits set to True or something.

I am not a fan of this.

> 1)      Say Nijmegen is going to support another platform, say Sun. Then it
> may turn out that Sun for instance does not support the lastModified field.
> Then you will be forced to move that field to the platform-dependent stuff,
> with undesirable consequences for existing applications.

Nijmegen supports the Sun platform (well, apart from many IO things like
ObjectIO, TCP...). The Directory module has been tested on a Sun. But back to
the subject: let's suppose somebody invents a new operating system which becomes
popular and which is not compatible with the interface in the Directory module.
Yes we have a problem then, but I don't think this is very probable.

>
> 2)      Or say the next version of UNIX supports creation time. Then you
> will be tempted to unify winCreationTime,  macCreationTime and
> unixCreationTime to creationTime, and to move it to the platform-independent
> stuff. Again with undesirable consequences for existing applications.

Yes.

> 3)      Even without any platform changes, a developer cannot currently
> create an application that is independent from whether the platform is mac
> or Windows, if (s)he wants to use the creation time, as (s)he would have to
> make the distinction between winCreationTime and  macCreationTime everywhere
> in the code. Just because a totally unrelated platform (UNIX) does not
> support it. I don't call that platform independence. I call that platform
> HYPER dependence.

getCreationTime (WindowsFileInfo {winCreationTime}) = winCreationTime
getCreationTime (MacFileInfo {macCreationTime}) = macCreationTime
getCreationTime (UnixFileInfo _) = abort "This program is not supposed to run
under Unix"


> The third mentioned possibility avoids these nasty things (but as said, is
> NOT ideal).

> I hope this inspires you to further improvements.
> Greetings,
>

At a certain point you cannot decide rationally anymore which solution is the
"best" or whether it's worth even to think about that. I'm happy with the
directory module as it is.

cheers
  Martin Wierich
  University of Nijmegen