Hello all

Good points have been raised about the current state
of Squeak's File Handling related classes' usability.
Specifically, the need for something a little easier
to understand and use.  

Lukas even posted some explanation unit tests of a
proposed class which prompted additional discussion
(and thus provided us with a possible first concrete
step towards an answer). Moreover, we were beginning
to build further on his initial thoughts about
possible solutions on these issues.

What do people think about the idea of seriously
considering going about refactoring these classes so
we can bring forwards some positive change on this
issue? 

Also, what do people think about the last suggestion I
posted?

This is sort of were we last left our discussion
off...

On Thu, 22 May 2003 09:33 Ned Konz wrote:
 
> On Thursday 22 May 2003 08:48 am, Julian Fitzell
wrote:
>> Anthony Adachi wrote: [...]
>>
>>> Although, I'm not sure what a good name might be
Filename sounds, to my
>>> ears at least, too much like simply a class
without any further
>>> responsibilities other than naming. It seems to me
that an object which
>>> might also be responsible for such things like
moving or copying speaks
>>> out for an name which sounds more like an entity
rather than a label or
>>> id.
>>
>> This is exactly my concern as well.

> We have several different things being discussed:
> 
> * file names themselves and operations on them (like
converting between
> platforms). With no context, this doesn't work well
(different
> filesystems have different rules), so you also have:
> 
> * file/directory structure information. Tied to a
particular filesystem,
> this can answer structure queries, ask about name
bindings (like
> providing stat() information), and gives operations
relating to existence
> testing, creation, deletion, renaming/moving, etc.
These can be files, or
> directories that can be iterated.
> 
> * files themselves. These are what's stored in a
filesystem. They don't
> necessarily have unique names. Operations on these
would including
> opening a stream, copying (kind of a
meta-operation), etc.

On Thursday, May 22, 2003, at 10:08  AM, Tim Rowledge
also wrote:

> But that would be the point of Filename; separate
out the ludicrously
> complex task of handling the naming of files so that
other classes can
> deal with the other parts. Plain good factoring.
> 
> You don't ask a Filename to rename or delete or
whatever. You just expect
> it to get the name right - which is not simple.

To which Julian Fitzell responded:

> Sure, but whatever class we're talking about *does*
rename, etc
> (according to the tests Lukas posted for
discussion). I don't disagree
> that there could be something that deals with file
names, but as Ned
> said, it would be hard for an object to do that
without any context. If
> we're proposing both a File and a Filename (or
whatever we're calling
> them), then that's fine too but that's different
from what has been
> discussed so far.

On Thu, 22 May 2003 22:33 John M. McIntosh also
commented: 

> Hint, on os-x you can represent file enties as URLs
and OS routines exist
> to map then between Posix file paths and os-9 file
paths. Just a
> thought... Should one have a URLs and map to/from
the platform file paths?

Responding to Ned and Tim I pondered:

"Perhaps, this suggests at least three different kinds
of classes for
 dealing with files?
 
In the order which Ned made his point about "different
things"...
 
 	*Filename
 
	* DirectoryItem with DirectoryNode/DirectoryContainer
and DirectoryFile
 subclasses 
 
	*FileContents or FileStream
 
I'm not trying to imply that these particular names
should be used but just to illustrate an idea of what
they might be responsible for."

Just something to consider,

Anthony

__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com