[ANN] Directory 1.0 released

Zuurbier, E. - AMSXE Erik.Zuurbier@klm.nl
Tue, 30 Nov 1999 09:56:51 +0100


(translation and slight extension of an earlier posting in Dutch)

Martin,

I had a quick look through the source-code. It looks nice. I will try it
soon; I already have an application waiting for this module. About
platform-dependency:
The Directory module itself is platform-independent. But complete
platform-independence is only achieved if applications, using the Directory
module, are by definition platform-independent. And that is not the case: if
an application uses the record-field winLastAccessTime, it cannot run on a
mac.
I see a number of different possibilities:
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,
or temporarily move/rename platform-dependent modules and try to re-link the
application, rather than sift through the whole source-code.
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.
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.

None of these solutions is ideal, but Peter Achten also got a long way
unifying platforms as far as GUI matters are concerned.
What does it mean for an appliation to be platform-dependent?
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.
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.
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.
The third mentioned possibility avoids these nasty things (but as said, is
NOT ideal).
I hope this inspires you to further improvements.
Greetings,

Erik Zuurbier, KLM,
co-mail: SPL/XJ-831
phone: +31 20 649 6255
email: erik.zuurbier@klm.nl <mailto:erik.zuurbier@klm.nl> 


		-----Original Message-----
		From:	Martin Wierich [mailto:martinw@cs.kun.nl]
		Sent:	woensdag 17 november 1999 17:48
		To:	clean-list@cs.kun.nl
		Subject:	[ANN] Directory 1.0 released

		A new Clean library to access and manipulate folders is
released for
		Windows, Unix and MacOS (PPC). It can be downloaded from

		   http://www.cs.kun.nl/~clean/

		cheers
		  Martin Wierich