FileDirectory>>fileExists: (was: Re: [BUG]Unable to load BFAV,
various problems )
Colin Putney
cputney at wiresong.ca
Thu Apr 22 20:10:56 UTC 2004
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
More information about the Squeak-dev
mailing list
|