Re: Proposal: An OOC Package Tool

[Tim Teulings <tim@edge.ping.de>]

Hallo!

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

This look like the C++ version of the solution.

STOP!

Before offering possible solutions to the problem we should first
define what the problem is!

Ok, here some questions we should answer (and there are very likely
much more :-)):

* What is the problem? Obviously it has something to to with packages
  and versions.

* What is a package. Some people told that we need versioning for
  modules, some spoke of "packages". While I have some idea what it is,
  I havn´t yet heard a detailed definition.

* Why do we need a package system? What do we like to gain from a
  package system (Sounds like a easy question, but who knows?)

* What about dependencies between module in a package / between
  packages?

* How about dependencies between packages, are they defined via the
  module dependencies or are they different.

* Some spoke about a directory for each package. Why do we need it? For
  compilation, installation? Should the knowledge about module
  placement be shown to the programmer or is this a implementation
  detail of the compiler, totaly hidden?

  Note, that I think a language should use a database-like interface
  to the modules. Each module has an absolute path within a virtual
  filesystem (perhaps a versioned file system), however the
  implementation of this database is totaly hidden from the user.
  Object and symbol file are stored in a - for the user unknown -
  seperate space. Perhaps even the *.Mod file should be copied
  elsewhere for automatic rebuilding purposes? During the (re)building
  process the user only sees its own modules and the resulting
  executable.

  There should be no limitations for a pathpart or total parth length.
  Module shortcuts ("IMPORT D := LongModuleName") are great.

* MvA has not yet spoke about installation details for its package
  system. As a result - while I´m in favour of reusing existing package
  systems like Readhat or Debian has - I´m not sure if these tools are
  sufficient. Perhaps You could give a list of keyfeatures (without
  implementation details, yet) you have in mind?



* How often is version a problem, must we find a powerfull solution or
  is a workaround, a simple solution adaquate?

  In my opinion the need of exessive versioning is a result of bad
  start design (changes to the interface break compability) and back
  hacking (versioning as a need for bug fixes). Normaly newer
  module/package version should enhance the interface while keeping
  compatibility with older version. As a result exessive versioning is
  a workaround for bad design/hacking as since we do not ddo such things
  we do not need it.

  Note, I´m not against it, I just think something as powerfull as the
  current Linux shared library versioning should be sufficent.

* How does the automatism work if no explicite version of a
  module/package is given (likely take the highes version).

--
Gruß...
       Tim.