Re: OOC Core Library

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

mva wrore:

> 
> 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.

Ok, one can always IMPORT Files := OakFiles; 

>      - 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.

But there should be some mechanism to recover it one cannot Register
a file. It could mean lost work for the user. The programmer should be
able to Register the file again if the first Register failed, possibly
with a program-generated unique name.

>   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.

Agreed.

>   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).

Every module could have a procedure to turn an error number into
a string. This also makes the error messages internationazible.
 
>    - 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.

Thats true, but I think filenames aren't much more than strings. They
are a way to identify a file. If all filenames on all OS'es were the
same we needed have bothered.


>    - RTS (access to the commandline and starting a program)
> [Knip]
>      - arguments are read-only.
>      - Called programs are not dynamically linked with the calling 
>        program.
> 
> I don't understand the last two points.  

The called program shouldn't be allowed to change its attributes. Too
system dependent.
We also need a way to call non-Oberon programs. These cannot be relied
upon to have the same semantics as Oberon commands. I think a routine
with the semactics of ANSI C system() is usefull, needed and also portable
enough.

>    I also think we need a runtime linker/loader like the module 
>    'Module' in the Oberon system. Otherwise the advantages of [knip]
> 
> 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).  

I think it is essential, because dynamic linking sets Oberon apart
from other compiled languages, AFAIK. Of course back-end writers
might not be able to implement it, but having a standard module
interface is a plus. There is nothing in the Oakwood guidelines
about this. Does Oberon/F has such an interface?


-- 
Sander

These systems people never changed. They could work miracles, but at the
same time they claimed perfectly reasonable requests were impossible.