Re: Proposal: An OOC Package Tool

[Christian Stork <cstork@ics.uci.edu>]

Michael van Acken <acken@vanacken.do.uunet.de> wrote:
>The interface of a package is versioned, e.g. using the libtool
>numbering scheme.  Versioning is based on the binary interface of the

Could you shortly explain this numbering scheme if it goes beyond simple
numbers for different interfaces?

>package's modules.  E.g., adding a record field to an exported type
>declaration results in a new package interface, because it could
>change the offsets of record fields and the record's size.

IMHO version numbers can only be used to there full potential if there
is some meaning attached to them.  Specifically, I suggest a version
number to consist of two nonnative integers x and y usually written as
x.y (I think here it shows that my background is mathematics ;)  Now,
the meaning is:

x - the main version number signifies an interface change or a 'serious'
change in behaviour ('serious' means that some client might depend on
it)

y - the minor version number signifies merely bug fix releases 

(for benefits of that definition see below)


Zem wrote:
>As far as versioning, what is wrong with saying ''IMPORT CO :=
>edu.uci.ics.lagoona.core.Collections.Version-7.0.1'?  Later on, one can change
>the version suffix and recompile.  You can even pull in multiple versions of
>the same package (well, several packages, really), and give all of them
>different aliases...

If you assume '.Version-7.0.1' to be part of the module name then
reasoning about the version number seems hard to me.

Assuming that this is just a notation for the version _number_ there are
two problems IMHO:

1) Modules cannot assume to be unique if several versions of the same
module are loaded concurrently.

2) All the clients of a module need updates when newer version become
available.


Thomas Kistler wrote:
> What you rather might wanna have, is individual version numbers for individual
> entities, such as procedures, or variables. You then just import
> edu.uci.ics.lagoona.core.Collections and if some entities require a
> special version number
> (e.g., because you work around a specific bug) then you might still
> be able to check
> the version number of the entity in the program at runtime:
> 
>    IF VERSION (foo.bar) < 5 THEN
>       Bailout ("Need at least version 5 of foo.bar");
>    ELSIF VERSION (foo.bar) > 7 THEN
>       foo.do (); (* without the fix, assuming the error has been corrected *)
>    ELSE (* for versions 5, 6, and 7 the fix is needed *)
>       (* "prefix" *)
>       foo.do ();
>       (* "postfix" *)
>    END;

In order to keep things as simple as possible I would not start to
define versions of procedures and/or variables.  I don't even see the
benefit in doing the above version checks.  A simpler solution would be
to have a simple way of saying that that module A requires the imported
module B to be at least of version x.y.  The problem of workarounds for
obvious bugs (or dependencies on unspecified behaviour) could be met by
providing modules which require certain versions of a module.  This
versioning scheme is designed to force the user to do an update to a
newer version of a module if this is available.  It is also designed to
force a check of each new version of the imported module by the client
module author if the bug still exists.

My tentative proposal would be a combination of some previous mails and
the above considerations. See for example:

FROM edu.uci.ics.lagoona.core 
IMPORT St := Stack, (* means: VERSION >= 0.0 *)
       B := Bag VERSION >= 0.4,
       Coll := Collection VERSION = 2, (* means 2.y, for all y *), 
       L := Longname VERSION = 2.5; (* probably too restrictive *)

I think this is pretty much self-explanatory.


With regard to Dirk's proposal to cleanly separate interface from
implementation I think this would be very desirable (and will certainly
be done in Lagoona) but it is currently not feasible in Oberon precisely
because of the phenomenon that Michael described:  even the addition of
*private* fields to an exported record type breaks binary compatibility
among modules.  Note that the interface has not changed.  This means
that wrt binary compatibility Oberon does not separate interface and
implementation.  (This is not true if you consider on-the-fly
compilation (Slim Binaries / Juice) as part of your language
definition!)

-- 
Christian Stork                         University of California, Irvine
mailto:cstork@ics.uci.edu               Information and Computer Science
http://www.ics.uci.edu/~cstork/         Bld. ICS 2, Room 243
+1 (949) 824 work -4121 fax -4056       Irvine, CA 92697-3425, USA