Re: Remarks on Files/Filenames

[Sander van der Wal <svdwal@xs4all.nl>]

On Wed, 10 Jan 96 5:31:35 EST acken@informatik.uni-kl.de (you) wrote:

> Rename, Delete and Copy should work on Filenames rather than File plus
> Filename.  These procedures are almost always called without the need
> to open the file.  Opening the file may be expensive for buffered
> files.  To do a Open -> Rename -> Close sequence to change a file's
> name is certainly annoying.

I was thinking about:

  f := Files.Old(Filename, res); 
  f.Rename(newFilename, res);

Files.Old does not 'open' a file or anything, the only thing you know
whether there is a File with the given Filename, and some of it's 
attributes.
 
> > (* read max LEN(b) CHAR's. 'howmany' indicates how many CHAR's are really read. *)
> > PROCEDURE (r: Reader) ReadString(VAR str: ARRAY OF CHAR; VAR howmany: LONGINT);
> This spec may lead to values in `str' that aren't terminated and
> cannot be manipulated with any of the Strings procedures.  What is the
> benefit of this proc compared to `ReadBytes' anyway?

You're right, 'howmany' is not needed for strings, because strings
must be terminated wit a 0X at the read end. A case of copying without 
thinking ;-) 
Type security and readability. ReadBytes is neccessary to read RECORD's
and ARRAY's, and can be used to implement most of the other PROCEDURE's.

 
> >    BinReaderDesc = RECORD
> >      PROCEDURE (r: BinaryReader) ReadBool(VAR b: BOOLEAN);
> >      PROCEDURE (r: BinaryReader) ReadSet (VAR s: SET);
> >    END;
> Those two procs only appear in BinReader/Writer.  I don't see any
> reason why we can't spend those types a textual representation and add
> them to TextReader/Writer, too.

I didn't either, but I've never felt the need for them. Maybe this is 
because most people read boolean values from text files in their native
tongue (YES/NO, OUI/NON, JA/NEE etc). Text representations for SET's
have the problem that you have to know the meaning and the position of 
all the members of the set. I think most people will do someting like
  
  member1: Y (or O, J etc)
  member2: N 

which is a lot mode understandable than 

  YN......
 
A possible text representation could be TRUE and FALSE for Boolean
vaules and {10101...} for set vaules.
 
> A GetDate procedure is missing.  Input: file name.  Output: time value
> plus error code.  How do we represent a time?  For Unix a time value
> is a record with a seconds and a microseconds field, both LONGINT.
> Anyone got a better idea?

Your right again, I forgot it. I think a separate DateTime-type 
will be best, with PROCEDURE's to 
  - test whether two datetimes are equal,
  - test whether one datetime is smaller than the other
  - test whehter a datetime is between two others
  - to create a datetime from year, month, day, hour etc
  - to make a string from a datetime.
  
The Files module (or equivalent) should export the minimum and 
maximum datetime a File can have. The datetime of the last 
modification should be a readonly parameter (I think this is what
most OS'ses do) , and there should be a SetDate-method. Writer's 
should update the datetime of their associated File.

 
> Some sort of test for file existence is necessary.  Input: file name.
> Output: TRUE/FALSE flag plus error code.  The error code is necessary
>Knip]

Currently it can be done with Files.Old. 

> A copy procedure would also be nice.  Input: source and destination
> file name.  Ouput: error code.

Ok.

> The OpenReader/Writer procedures should probably be type-bound procedures.

Ok.

> Filenames: I'm missing any way to represent directories different than
> strings.  Maybe it would pay of to split a file name into a directory
> locator plus file name/extension.  A system-independent facility to
> get a directory's file listing would also be nice.  But I don't now if
> this is feasible at all.
 
I think a Directories or FileDir module is feasable. A FileDir.Old
procedure will have a Filename as it's input parameter. A FileDir.
Enumerate will return a File or a FileDir. For this to work File
and FileDir should be derived from something more basic, like a
DirTreeEntry. This object will have the same attributes as a File
in my Files module, but no Riders can be associated with them. 

> Just my two cents for now.  I hope that Files and Filenames will be
> intgrated into a more general class hierachy based on locators and
> channels.

As soon as I know exactly what a Locator and a Channel is, this should 
be no problem. Besides, by not saying that a Filename is some kind
of Locator does not mean is isn't, mainly because clients of Filename
are interested in the Filename-aspects of the Filename, not if they are
derived from a more abstract class.

-- 
Sander        

We get to pick tools and equipment that suit the job.  We spend nearly all our 
time programming ART's computer's. (~P.J.Plauger: Programming on Purpose III)