FileDirectory>>fileExists: (was: Re: [BUG]Unable to load BFAV, various problems )

Doug Way dway at mailcan.com
Thu Apr 22 18:23:41 UTC 2004


Colin Putney wrote:

>
> On Apr 20, 2004, at 1:13 PM, Tim Rowledge wrote:
>
>> Ignoring for the moment Russell's point about the file naming issue
>> (since file names should be a separate class to filestreams etc anyway)
>> I would suggest that we would benefit from a single FileDirectory class
>> BUT that said class needs a bridge to the actual machine primitives.
>
>
> Hear, hear!
>
> I'd also like to see a FileLocator class that provides a 
> cross-platform reference to a file. It would implement a protocol for 
> dealing with files - #open, #delete, #moveTo: etc, and delegate the 
> actual operations to a platform-specific bridge.


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?)

People are bringing up the possibility of using a URL/URI class to do 
this, but I'm not sure that would work.  The current URL/URI 
implementations all assume read-only access, and we want to be able to 
do things like deleting and renaming files... basically the protocol you 
mentioned.

So perhaps we should drop the URL/URI idea and just go ahead and create 
a FileName class or similar.  (Said bluntly to encourage discussion. ;-) 
)  Or would it actually make sense for a URI to support Colin's protocol?

(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.)

- Doug





More information about the Squeak-dev mailing list