Re: Proposal: An OOC Package Tool

["Peter H. Froehlich" <phf@acm.org>]

Hi there!

[Note that I am "crossposting" this to the Lagoona mailing list. Please
keep the crosspost intact as long as the discussion remains interesting
there. Thanks.]

At 5:47 PM +0200 4/5/99, Michael van Acken wrote:
>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.

   We are currently thinking about adopting Java's naming convention for
"packages" in Lagoona. This would (in essence) still constitute a "flat
namespace" however the compromise of settling for "reverse domain names"
prefixing the actual module name seems to be the best one to make in terms
of transparency and utility.

   For example the basic collection framework for Lagoona would be
contained in a module named "edu.uci.ics.lagoona.core.Collections" and one
could use this "ugly" name together with the existing "abbreviation"
concept:

   IMPORT CO := edu.uci.ics.lagoona.core.Collections;

Semantics of this should be obvious. So far we did not spot any severe
problems with this, so if someone sees any, feel free to point them out. :-)

   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?

   Of course the above might seem slightly "off topic" anyway since you are
mainly thinking about configuration management issues, not necessarily
language design issues as such. However your proposal (as far as I
understood it) is not really "complete" then because it disregards
versioning. See below.

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

   Okay, my first objection regards versioning. If you want to establish a
working "package" concept for configuration management it should be
possible to request a certain version of a package (or module) in order to
make sure that workarounds that might exist in client code can be properly
dealt with.

   Assume that my client module was developed against package "foo" version
7. During development I detected an error in that package that I work
around in my module. Presumably I pass on the information about this error
to the author of "foo" but to ship my client now, I have to include the fix
anyway. What I would then like to do is the following:

   IF VERSION (boo) < 5 THEN
      Bailout ("Need at least version 5 of foo.bar");
   ELSIF VERSION (boo) > 7 THEN
      boo.do (); (* without the fix, assuming the error has been corrected *)
   ELSE (* for versions 5, 6, and 7 the fix is needed *)
      (* "prefix" *)
      boo.do ();
      (* "postfix" *)
   END;

Or do you want to deal with things like that in the "package tool"? Then
that tool would have to include a quite elaborate "sublanguage" similiar to
the C preprocessor, wouldn't it? Of course, this would still not allow for
behaviour dependent on the *runtime* version of "foo.bar".

   The other objection is against the addition of only one "level" of
packages because that is isomorphic to just prefixing module names without
any easy and sensible conventions except for a "global registery"
maintained by some central authority specifically for Oberon (or worse
OOC). In order to minimize name clashes, the Java-like approach seems to be
better.

   One last bit of motivation: For Lagoona we are looking for ways to
integrate these issues (unique names, versioning, etc.) into the module
concept in order to avoid the introduction of a separate "package" or
"subsystem" concept into the language.

   This has also been mentioned by Clemens Szyperski in his 1992
dissertation "Insight ETHOS". The following quotes what he had to say about
it:

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

Okay, sorry for the long posting, but I hope to have contributed at least a
somewhat relevant view on this issue. Feedback is highly appreciated! :-)

By(T)e...         /  Graduate Student @ http://www.ics.uci.edu/  \
         Peter... \ More Infos @ http://www.peter.froehlich.com/ /