On Apr 22, 2004, at 1:23 PM, Doug Way wrote:

> Yes!  Actually, I think that's roughly what Tim meant by "file names 
> should be a separate class" anyway.  Although I would probably give 
> such a class a simpler name such as FileName or possibly File.  (I 
> suppose FileName may be a better name because "File" may imply a 
> stream on the file contents.  Although I personally like File 
> better... in English, you delete a file, not a filename.  You open a 
> file to get a filestream.)
>
> This would clean up a lot of the embarassingly non-OO code in 
> FileDirectory such as FileDirectory>>deleteFileNamed:... you would 
> just send #delete to a FileName.
>
> (Or would a FileLocator be more than just a file name?  Would it have 
> an #exists accessor?)

I guess File would be OK, but I don't like FileName. It's not a name, 
it's more like a pointer to the file. It should implement #exists and 
#create.

> (And the idea of having a single FileName class which maps to the 
> appropriate platform primitives sounds fine to me, rather than having 
> UnixFileName/Win32FileName/MacFileName/etc subclasses.)

I'll take Tim's side here. I'd like to see File be completely 
cross-platform, and deal with a Peer (or Bridge as Tim called it) 
rather than calling primitives directly. So we'd have UnixFilePeer, 
Win32FilePeer, CarbonFilePeer, AcornFilePeer etc.

Lets assume that the file system is hierarchical. (We don't currently 
support any that aren't, do we?) File could contain an isAbsolute flag, 
and an array of tokens. The peer for the current filesystem would take 
those tokens and do some kind of platform-specific resolution. 
UnixFilePeer might glue them together with $/ to make a path that it 
could pass to the unix primitives, CarbonFilePeer might look up the 
file reference number (or whatever, it's been a loooong time since I 
read Inside Macintosh), AcornFilePeer would do it's cool-but-obscure 
thing. The resulting platform specific state would stored in the 
instance variables of the peer.

The key thing here is that each platform can have it's own set of 
primitives which make sense for that platform, and the peer can have 
state that makes sense for those primitives. Smalltalk code never deals 
with the peers, just File, and the peers are *not* subclasses of File.

Colin