Doug Way wrote:
> 
> Stephan Rudlof wrote:
> >
> > BTW: I've found it annoying, that there isn't a - possibly - abstract
> > class which handles Files and Directories unique and has some tests like
> > - isExistingFile,
> > - isExistingDir,
> > etc. working with the path.
> > Currently you have to be careful:
> > If you say FileDirectory on: '/tmp/foo' you get a FileDirectory with
> > '/tmp' and don't know if 'foo' is a dir or a file.
> 
> I agree.  I'd go a bit further and say that the FileDirectory stuff is a mess,
> it's probably my least favorite class in all of Squeak.
> 
> The main problem is that you can't simply represent a single file name with an
> object.  You could then send this object simple messages such as "delete",
> "exists", "openAsStream", "renameTo:", etc.  With FileDirectory, you have to
> pass the name of the file as a parameter for most of its messages, which seems
> rather un-OO.  If I want to keep track of a file, I need to store both the
> FileDirectory and the name of the file separately.  (I haven't used VisualWorks
> in a few years and have forgotten most of it, but I still fondly remember the
> way it handled file names. :-) )
> 
> Perhaps I'm overstating things... but I only deal with files occasionally in
> Squeak, and it always seems to take me a while to figure out how to do
> something.
> 
> Even just an abstract class which handles something like "isExistingFile" and
> "isExistingDir" would be helpful, as you suggest... I guess I'd have to think
> about what the best hierarchy would be for implementing this...

I have a first idea (not especially new I'm sure!):

What about creating a Path class which has
- a pathString as instVar;
- messages like
	- 'inside path moving':
		- up (for moving from dir2upperDir and file2containingDir), up: (for
more than one up's),
		- upDir (moving from file2containingDirOfContainingDir and
dir2upperDir), upDir:,
		- addLocalPath: (to make a path longer);
	- 'testing': isFile, isDir, isWritable, isReadable, isExistent or
exists;
	- 'file operations':
		- renameTo: (like in FileDirectory, argument has to be a full path),
		- delete (dangerous!, so there could be more or less careful
subclasses),
		- moveFileTo:, copyFileTo: (if it's not a file, generate an
exception),
		- moveDirTo: (if it's not a dir, generate an exception),
		- copyFilesInDirTo:, moveFilesInDirTo:,
		- copyContentsOfDirTo:depth: (copy recursive all files and dirs until
depth is reached),
		- openAsReadStream, ...,
		- compressTo: (could be made also for dirs, if there would be a
recursive gzip),
		- etc. (there are more).

The 'inside path moving' methods were just String operations, the
'testing' and 'file operation' methods could be implemented by using
FileDirectory as 'private' implementation class.
If a local Path without leading '/' (under Unix, volumes for DOS/WIN,
etc.) is given, it is just appended to the current Path before
performing methods with paths as arguments (similar as in FileDirectory,
but in opposite local names can be paths and needn't be without path
delimiters).

This seems to be an easy to implement straightforward approach.

> 
> I know, I know, I should post a changeset rather than complain. :-)

Unfortunately I don't have any time left now to start with it...

Greetings,

Stephan

> Didn't
> Craig Latta or someone post some sort of improved file name handling changeset
> awhile ago?  (I guess changing this would require a lot of cleanup in the base
> image...)
> 
> - Doug Way
>   EAI/Transom Technologies, Ann Arbor, MI
>   http://www.transom.com
>   dway at mat.net, @eai.com

-- 
Stephan Rudlof (sr at evolgo.de)
   "Genius doesn't work on an assembly line basis.
    You can't simply say, 'Today I will be brilliant.'"
    -- Kirk, "The Ultimate Computer", stardate 4731.3