From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,88ed72d98e6b3457 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-10-09 08:21:04 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!nntp.cs.ubc.ca!freenix!ircam.fr!news.completel.fr!nntpfeed-01.ops.asmr-01.energis-idc.net!news2.euro.net!newsfeed.freenet.de!151.189.0.75.MISMATCH!newsfeed.arcor-online.net!news.belwue.de!news.uni-mannheim.de!errigal!lucks From: Stefan Lucks Newsgroups: comp.lang.ada Subject: Re: Standard Library Interest? Date: Thu, 9 Oct 2003 17:18:35 +0200 Organization: Rechenzentrum Uni-Mannheim Message-ID: References: <3F7F760E.2020901@comcast.net> <3F8035B0.7080902@noplace.com> <3F816A35.4030108@noplace.com> <3F81FBEC.9010103@noplace.com> <6Ingb.30667$541.13861@nwrdny02.gnilink.net> <3F82B4A4.5060301@noplace.com> <3F82F527.3020101@noplace.com> <3F846B5E.9080502@comcast.net> <3F855460.6020804@noplace.com> NNTP-Posting-Host: errigal.informatik.uni-mannheim.de Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: trumpet.uni-mannheim.de 1065712718 11275 134.155.91.80 (9 Oct 2003 15:18:38 GMT) X-Complaints-To: usenet@trumpet.uni-mannheim.de NNTP-Posting-Date: Thu, 9 Oct 2003 15:18:38 +0000 (UTC) X-X-Sender: lucks@errigal.informatik.uni-mannheim.de In-Reply-To: <3F855460.6020804@noplace.com> Xref: archiver1.google.com comp.lang.ada:540 Date: 2003-10-09T17:18:35+02:00 List-Id: 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! ------