Re: OOC Core Library

[acken@informatik.uni-kl.de]

   From: Sander van der Wal <svdwal@xs4all.nl>

   The advantage of including In and XYPlane is that one can run the
   examples in 'Programming in Oberon'. No need to use them in the
   compiler itself. This should probably at the discretion of the
   porter.

I do vote for providing the set of Oakwood modules, but only as
add-ons to the standard library.  And I positively hate the idea to
call the `real' Files module something different because Oakwood has
already a module named `Files'.  I'd prefer to rename the Oakwood
stuff into something like `OakFiles', `OakIn', etc.

   - Files: 
     [snip]

     other stuff
     - I'm not sure whether there should be a directory system.
     - The Files.Register trick of Oberon is a bit expensive to implement
       on the file systems I know (Unix, DOS, RISC OS). I think a 
       module TemporaryFiles is easier.

`Register' has its advantages in a multi-tasking environment if you
define it as an atomic action.  This guarantees that your file appears
in the file system exactly like yu have written it, regardless of
other tasks writing to the same file (or rather: file name).  It isn't
that expensive to implement if registering is just a `rename'
operation.  But Unix doesn't allow renaming accross file systems, so
o2c implements it as copy, which is expensive, of course.
  Error handling is also a point to consider.  When buffering reads
and writes, an error may be detected only at the point of closing the
file, ie when the buffers are flushed.  Oakwood Files doesn't allow to
report an error from Close, and calling Close is optional.  So with
o2c you are never quite sure if your file was written correctly.  This
is something I don't want to see repeated in OOC.
  Here are some alternatives for error handling:
- read error: abort with error message OR set error flag 
- successive read after error: do nothing OR return some default values
- write error: abort with error message OR set error flag
- successive write after error: do nothing
- delete/rename/register/close/etc: abort OR return error flag
The `abort' stuff should just be an option (if it's part of the module
at all).  The error flag should probably an attribute of the File (not
Reader or Writer).  A mechanism should exist to get a textual error 
description if a operation failed (eg, a Rename may fail because of a
number of reasons: no source, no dest dir, dest exists, etc).

   - Filenames:
   [snip]

Good idea to turn file names into objects.  After all, we got a OO
language.  So why not use its features?  And an object is more
powerful and can hide more system dependencies than a mere array of
character.  We should find another module name, though.  `File-names-'
is too closely associated with strings.

   - RTS (access to the commandline and starting a program)
     - argument separators should be parsed according to system 
       conventions ( -, / etc). The argument separators should be 
       invisible. A program should supply a list of acceptable
       argument names. 
     - arguments are read-only.
     - Called programs are not dynamically linked with the calling 
       program.

I don't understand the last two points.  

   I also think we need a runtime linker/loader like the module 
   'Module' in the Oberon system. Otherwise the advantages of 
   dynamically linked modules are lost. Whether a port supports
   it is another matter. This is useful when one wants to build
   a cross-compiler, and it is a big plus for Oberon-2 compared
   to C++. 

Agreed.  Especially in the context of persistent objects and sharing
objects (and code!) accross program boundaries it is a BIG plus.  This
will increase the complextity of a back-end's run-time system
somewhat, but I think it is worth the trouble (if it is possible at
all).  

-- Michael van A.