FileDirectory>>fileExists: (was: Re: [BUG]Unable to load BFAV,
various problems )
ducasse at iam.unibe.ch
Thu Apr 22 19:02:52 UTC 2004
I know that lukas started to write a library to abstract file and so
that we could transparently
deal with file and uri, ftp.... there is a first draft may be on
squeaksource but you can ask him.
I'm sure that you can help, look at what he did.
On 22 avr. 04, at 20:23, Doug Way wrote:
> 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
>>> I would suggest that we would benefit from a single FileDirectory
>>> 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