Re: Standard Library Interest?

[Stefan Lucks <lucks@th.informatik.uni-mannheim.de>]

I like the baby-step proposal. 

However, such a standard library would rather be a collection of different
sublibraries (typically packages), and the interfaces would not always be
consistent. That is unavoidable, and most programmers could live with
that. (Even e.g. the JAVA library is not always consistent, though its
designers did seriously try ...)

One problem with any library is that you may be using different versions
on different platforms. Another problem is that if you fetch the library
from some web site (which is assumed for the baby-step propoal), you may
first want to check if it runs in your environment at all.

[...]
> to the "right" guidelines. Otherwise, its just another inconsistent mess
[...]

One thing that might significantly improve the acceptance for such a
collection of (sub-)libraries would be to support a *standartised*
*interface* at least for

  1. a unit test for the package and

  2. checking the current version number of package

This would help people to actually integrate these library packages into
their stuff, doing automatic unit and integration tests ...

Also, this does not seem to hinder the integration of already existing
libraries into the standard library:

  --  Dealing with the version number is trivial, anyway.

  --  Assuming the authors of the already existing library did implement 
      unit tests for their library at all, writing one additional 
      procedure for doing the full unit test can't be too difficult.


Consider you *with'ed* the package "some.weird.package_name" from the 
standard library. Without having to look into either source code or other 
documentation, I'd like to compile and then run a unit test by calling:

	some.weird.package_name.Full_Self_Test(0);

The "0" indicates "accept no errors", see below.

Checking the version number should be done similarly. You can't always
prevent version skew, but can automatically detect potential problems.


> BTW: I'd propose "CAL" as the root package name and from there, you can 
> have "CAL.Statistics". But be sure to build the statistics stuff 
> utilizing whatever comes under "CAL.Containers". ;-)

Here an example (using "CAL" as the root package):

CAL.Containers.Bags.Full_Self_Test(expected_number_of_errors => n);
  -- raises an exception if not exactly n tests fail 
  --   (usually: n=0, but sometimes you may want to "with" a package
  --    even though you know that the unit test reveals some bugs)

CAL.Containers.Bags.Require_Version_Number(3, 14, or_newer => true);
  -- raises an exception if version of CAL.Containers.Bags is 3.13 or 
  -- older; does not raise for newer versions, such as 3.15 or 4.2
  -- if or_newer is false (default), then Require_Version_Number raises if 
  -- the version number is not exactly 3.14. 

-- now start doing your real stuff, e.g.:

CAL.Containers.Bags.Insert(the_bag => my_bag, the_item => my_item);


The above is just an example. Perhaps some of you have better ideas for
the actual interface to do a unit test and to check the version number.

Note that both unit test and version number deal with CAL.Containers.Bags
in the above example, (i.e., with the "innermost" package) not with
CAL.Containers or even CAL itself. I am not sure, whether a package should
be hold responsible for its child packages. A package such as
CAL.Containers may not even know all of its child packages, right?

In other words, for CAL and CAL.Containers we should avoid to call (or 
even implement) Full_Self_Test and Require_Version_Number ...

-- 
Stefan Lucks      Th. Informatik, Univ. Mannheim, 68131 Mannheim, Germany
            e-mail: lucks@th.informatik.uni-mannheim.de
            home: http://th.informatik.uni-mannheim.de/people/lucks/
------  I  love  the  smell  of  Cryptanalysis  in  the  morning!  ------