[squeak-dev] Re: [ANN] Filesystem 1.0

Andreas Raab andreas.raab at gmx.de
Sat Nov 21 23:22:02 UTC 2009


Colin Putney wrote:
> On 21-Nov-09, at 12:29 AM, Andreas Raab wrote:
> Awesome. Thanks for trying it out. Would you send me that code, so I can 
> see the areas that were problematic with a bit more context? I'd like to 
> make this simpler.

Sure. Attached are the changes (relative to FileList in trunk).

>> 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).
> 
> Yeah, I can see this is an issue. The idea is to use FSReference 
> everywhere. Filesystems and paths are meant to be the low-level 
> implementation mechanism for references, and you shouldn't have to deal 
> with them unless you're doing something exotic. Clearly the tutorial is 
> actually confusing more than it's enlightening; I need to put references 
> front and centre, and maybe mention paths and filesystems in passing.

I think you should change the terminology slightly. Having the 
implementation specific thing called "path" and the user visible entity 
called "reference" is confusing - when I was looking at the code I saw 
"oh, there's a path, yeah, that's what I'm looking for". The term 
"reference" didn't ring a bell with me. In other words, I would have 
users deal with FSPath objects and rename the current FSPath to 
something obviously obscure, for example "FSPathSequenceImpl" or 
something to make obviously clear that from the user perspective you're 
going to deal with the FSPath only.

FWIW, I didn't find the usage of file system as confusing; the only 
confusion arose from having to deal with them due to the windows drive 
letters (but see below).

>> 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.
> 
>> 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.
> 
> One fo the advantages of the current arrangement is that all of the 
> filesystem-specific code is a subclass of FSFilesystem. If I start 
> having FSWindowsPath and FSUnixPath and FSZipPath, it gets harder to 
> make things uniform and transparent across different filesystem 
> implementations and harder to extend the system with new filesystems.

Absolutely. But I don't think you'd have to change the arrangement at 
all. The idea is that on Windows there is a virtual root of the file 
system and all shares and drive are logically subdirectories of that 
virtual root. This works fine and really the only difference is printing.

The easiest way to experiment with that is by just removing all of 
FSWindowsFilsystem stringToPath:, stringToReference:, 
forReferencePrintOn: and fix up pathToString: to not print the disk. At 
this point you can already do stuff like:

   FSDiskFilesystem current stringToReference: 'D:\Squeak\3.10'.

Which shows the idea. After which things break mostly because there are 
a few tricky Unix assumptions in the code, for example 
FSPath>>isAbsolute. The assumption that you can tell in a context-free 
manner whether a path is absolute or not will cause grief if you need to 
be able to distinguish /foo/bar from \\share\dir from c:\windows etc. 
Even more tricky, \Windows\system32 is not an absolute path in any 
meaningful way on Windows. I would vote for being explicit here and have 
FSRelativePath that the file system can construct appropriately.

[... two hours later ...]

Ah, what the heck. I just spend two hours fixing things into shape the 
way I think it should work. Attached you'll find my patches which 
implement the above. Check it out and you'll see why I'm saying there is 
no real difference in arrangement. Let me know what you think about that 
direction. The patches allow one to use '\\server\path\to\file' as well 
as 'c:\windows\system' etc. The tests pass, too :-)

Cheers,
   - Andreas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: FSFileList.3.cs.gz
Type: application/octet-stream
Size: 2531 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20091121/4f26a8d5/FSFileList.3.cs.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: FSWinPatches.3.cs.gz
Type: application/octet-stream
Size: 3896 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20091121/4f26a8d5/FSWinPatches.3.cs.obj


More information about the Squeak-dev mailing list