Re: OOC Core Library

[acken@informatik.uni-kl.de]

From: Guy Laden <laden@math.tau.ac.il>
Subject: Re: OOC Core Library
Date: Fri, 1 Dec 1995 17:11:05 +0200 (GMT+0200)
In-Reply-To:  <9512010452.aa28688@bordeaux.informatik.uni-kl.de> from "acken@informatik.uni-kl.de" at Dec 1, 95 04:52:54 am

[Guy accidentally directed this mail to me personally and asked me to
 forward it the list.  --mva]

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

We need a namespace management system.
The Oberon/F model is not flexible, but its _simple_. Perhaps we
could somehow integrate it with the ~/.o2rc approach.
If backends do provide dynamic linking, they too will need somekind
of system for finding the modules.

>    - 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.
Oberon/F uses 'Locator'
If we do module Files right, a Locator can be extended into supporting
URL's with no changes to the module client.

> 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 agree.
At first at least, perhaps we could use existing Oberon-Systems as dynamic
linkers/runtime envs?
With V4 sources coming out...
Could ooc produce Oberon V4 object files?

Guy.