[squeak-dev] Re: [ANN] Filesystem 1.0
Andreas Raab
andreas.raab at gmx.de
Sat Nov 21 08:29:48 UTC 2009
Colin Putney wrote:
> I expect that to improve, but in the meantime, it's possible to use
> StandardFileStream with FSDiskFilesystem subclasses, and there are
> compatibility streams for FSMemoryFilesystem and FSZipFilesystem. So
> it's possible to start using Filesystem to replace FileDirectory, and
> keep using FileStream until the FS stream implementations mature. To put
> it another way, compatibility with FileStream is a non-goal for the
> design of the native FS streams, but having a smooth migration path *is*
> a goal. I've got legacy code that I need to convert!
Thanks. I thought I'd give it a quick try and port the first thing that
came into my hands which was FileList. Here is some feedback:
From a Windows perspective, the handling of drives and file systems is
quite awkward. I would strongly suggest that you drop the idea that
drives (or shares) are part of the file system and rather move them into
the path representation. Otherwise you end up with code like here:
"Figure out the #localName of the directory to display"
localName := aDirectory path basename.
"On windows, the local name may be empty and we must look at the
embedded filesystem's drive field instead"
(Smalltalk platformName = 'Win32' and:[localName isEmpty])
ifTrue:[localName := aDirectory filesystem printString].
I mean, eeek. There are several other places where one needs to do stand
on one's head to do things mixed with drives and paths on Windows which
will make it significantly harder to write cross-platform code. Just
consider for example the root directories that we'd like to display in
the file list. Here is how this looks today:
roots := FileDirectory root directoryNames.
and now with Filesystem:
Smalltalk platformName = "Win32"
ifTrue:[^FSWindowsFilesystem disks collect:[:wfs| wfs root]]
ifFalse:[^FSDiskFileSystem root entries select:[:d| d
isDirectory]].
Etc. The problem is fairly persistent and needlessly so given that
treating the drives and shares like virtual directories gives one
everything that's needed for dealing nicely with the cross-platform
aspects while being able to do the Windows-specific stuff just as well.
What I would propose here is that you keep the filesystem distinction
(so that someone is able to ask a question like: is this on the same
file system?) but move the drive letter / share name into the path.
Another issue I found bothersome was FSReference vs. FSPath. It is very
unclear to me when you use one or the other and given the difficulty to
distinguish FSPath from FSReference visually I would strongly vote for
making them one and the same to reduce confusion (see FSFilesystem
workingDirectory which returns an FSPath vs. FSFilesystem root which
returns an FSReference etc).
Some smaller issues:
* FSFileSystem root prints incorrectly 'C:/' instead of 'C:\'
* FSWindowsFilesystem>>disks should return an ordered array (C: should
come before H:)
* There is no #size on FSReadStream?
Other than that I got a basic port of FileList working. It's definitely
work to port things over, it doesn't come for free. I think there are a
few things that could help migration significantly, most importantly
implementing #localName and #fullName on FSReference and
#modificationTime (in addition to #modificationSeconds) on
FSDirectoryEntry because they are so commonly used.
Cheers,
- Andreas
More information about the Squeak-dev
mailing list
|