Re: Proposal: An OOC Package Tool

[Marco Oetken <Marco.Oetken@informatik.uni-oldenburg.de>]

This Mail has 3 topics:


1> THE PACKAGE SYSTEM USED ON MY LINUX
2> HIERARCHICAL MODULE/PACKAGE SYSTEM - PART 1
3> PART 2 (LAGOONA)


Michael van Acken wrote:
> 
> Oberon was designed as an extensible from the very beginning.  But
> extending an installation by adding new modules and programms has
> always been a very low-level operation.  This process can be made much
> more user friendly.  Here is an outline of an OOC Package Tool,
> tentatively called "oopt" for now.  I would like to know if anyone
> supports the idea of such a beast.

1> THE PACKAGE SYSTEM USED ON MY LINUX
MkLinux (as RedHat and SUSE) uses the RedHat Package Manager (RPM),
RPM supports dependencies, automatic execution of scripts and
ftp-installation. (It has a graphical interface for the basic
operations [needs X11].) As far as I understand your visions, 
RPM is suitable. There are other tools which provide similar
functionality. It should not be required to implement a new package
tool (although it might be the better solution).

The drawback in mixing different tools is
- the need for different tools
- different facilities of those different tools.

[...]


2> HIERARCHICAL MODULE/PACKAGE SYSTEM
> Oberon-2's relationship to packages is, simply put, non existent.  The
> single flat namespace for modules sucks.  It is strange that a system
> designed for extensibility has no means to keep the complexity of
> managing extensions at an acceptable level.  Prefixing all modules of
> a package with a unique string is a step in the right direction, but
> at the same time it's only a half-hearted attempt.  There is still
> just a flat name space, and there is no way to associate packages with
> meta information as long as the compiler does not know anything about
> packages.
> 
> To pass package information to the compiler, I propose a minimalistic
> change to the Oberon-2 IMPORT statement.  In addition to the import
> clause
> 
>
>
>   ident [":=" ident]
> there is a second variant,
> 
>   ident := ident {"." ident}
> 
> to access a module from a package.  A module `bar' from package `foo'
> would be imported as "IMPORT boo := foo.bar".  The statement "IMPORT
> foo.bar" is not allowed, which means that there is no need to change
> the rule for "Qualident".  The rest can be handled by the compiler.
> 
> To turn "package aware" source code into standard O2 source code, it
> can be passed through oocn for some simple IMPORT rewriting.
> 
> There.  Let the flame wars begin.
> 
> -- mva

I have been thinking about the flat namespace, too. My idea was to change
the import statement to:

  FROM package IMPORT    ident [":=" ident]

where package could be any hierarchical name. This would allow
for the following:

  FROM VO IMPORT Object, DragAndDrop,
                 g := GUIObject;

or 

  FROM GFX/VO/Version1.1 IMPORT Object, DragAndDrop,
                                g := GUIObject;


A problem which remains is how to manage the hierarchy. My idea was
inspired by the Macintosh filesystem:
  When you add an application file to the running system, the
  MAC OS will recognise it as a program and conditionally start
  it. 
I actually don't know how the MAC OS manages this, but I think
it has some kind of database with all "installed" programmes,
which is updated by simple filesystem operations like move, copy
or delete. An application is recognised by a resource entry.
There is no equivalent on a unix system.


3. HIERARCHICAL MODULE/PACKCKAGE SYSTEM (LAGOONA)

Peter Froehlich wrote about Javas naming convention (which I don't
know) and suggested the following IMPORT:

>   IMPORT CO := edu.uci.ics.lagoona.core.Collections;
The first part of the name seems to me like a part of a WWW-address.
Does this imply a download from a server or does it reflect a locally
existing hierarchy?

>    We have also thought about a "truely hierarchical" namespace, however
> that would introduce subtle problems regarding the strict encapsulation we
> require modules to support. It all centers around the question whether
> identifiers from "upper level" modules should be useable *implicitly*
> within "lower level" modules. This would be in line with usual scoping
> rules (as used for procedures) however it would clearly also break
> encapsulation. If on the other hand implicit access is not allowed, what is
> the point of having "nested modules" in that form in the first place?

I don't think that there are "upper level" or "lower level" modules.
I see a hierarchy of packages not a hierarchy of modules. How should
a module be nested in another one? This could be a way, too, but I
prefer the former, which avoids this problem.

>    "To allow for nested structuring of larger systems, it would be helpful if a
>     module can be used to encapsulate a group of modules without introducing
>     efficiency problems. The concept of separating systems and modules  - where
>     systems are kind of super-modules used to group modules and other systems -
>     proposed by Cardelli [Car89] is not recommended. Instead of introducing
>     another concept, the module concept itself should be made flexible enough.
>     For example, a module should be able to re-export arbitrary parts of other
>     modules."
I have been thinking about some kind of distinction of packages.
My idea was to have "open" and "closed" ones. Closed ones would
provide a module which acts as an interface for clients outside
this package. Within the package each Module has access to the others.
Only from open packages different modules may be imported. I think that
this could be a place for the above mentioned modules with re-export
capabilities.