Ned Konz wrote:
> On Wednesday 21 May 2003 05:25 pm, Julian Fitzell wrote:
> 
>>I posted something about this a few weeks ago.  I think we should
>>look at having File class, rather than a Filename (unless we
>>perhaps want both).  The File class would obviously know the name
>>of the file it represented and would be able to provide you with a
>>stream on that file. It could also provide operations to rename the
>>file, etc.  Haven't thought too much about the details or possible
>>issues, but it seems to me like a good idea on the surface, anyway.
> 
> 
> But filenames aren't something that files have. They're something that 
> is maintained by something else that's keeping a set of name 
> bindings.

Hmm... that's true.  I guess what I'm thinking of really is more like 
one view of a file than the file itself.  Which I admit sounds an awful 
lot like a Filename :)  It just feels like if you're going to call your 
object Filename, your methods really need to be like #deleteTarget or 
#deleteFile rather than just #delete (since you aren't deleting the file 
name, you're deleting the file).

Perhaps that's being pedantic... it just doesn't feel like the object is 
really representing a filename; it's representing a theoretical file 
that might or might not exist inside a box specified by a filename.

I personally fine it clearer to speak about a File object representing a 
file that might not actually exist yet, than to speak about calling 
#delete or #writeStream on something called Filename.  But I do entirely 
see your point, so I'm not sure File is right either.  Perhaps there's a 
better name than either of these that really captures what we're talking 
about?

> I can get to the same file by multiple names, even in the same image 
> (via links, mounts, or other mappings).
> 
> And of course we can have streams whose names we don't know (stdin, 
> stdout, pipes...).

Sure, but we're not talking about repplacing streams here.  Files, or 
Filenames, or whatever just know how to provide a stream. Right?

> We need Filename operations to make it possible to talk about files 
> that don't or won't exist. Before you create a file, you've still got 
> to deal with its name.

See my point above.  A file's name is a string.  It's something that I 
might want to capitalize or display in a dialog, etc.  Are we going to 
have Filename>>filename that returns the file name?  Seems a bit odd.

> Plus, we've got to be able to do cross-platform name operations of 
> some sort. I ran into some problems with the ZipArchive, since it 
> stores its paths in a standard format that then must be translated to 
> local filenames.

Yes, this will be problematic any way we cut it.

> There were suggestions about unifying Filename and file:// URL 
> handling at some point.

Julian