Xref: utzoo comp.object:3405 comp.lang.eiffel:1553 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!wuarchive!uunet!igor!rutabaga!jls From: jls@rutabaga.Rational.COM (Jim Showalter) Newsgroups: comp.object,comp.lang.eiffel Subject: Re: Unification: Class=Type=Module Message-ID: Date: 30 Apr 91 02:26:28 GMT References: <1991Apr23.142800.12215@bony1.bony.com> ,<1991Apr25.074758.6153@jyu.fi> <00947B3D.46D89E40@uno.edu> Sender: news@Rational.COM Followup-To: comp.object Lines: 29 ]>Using the module facilities in Ada and Modula2, I have always been of the mind ]>of using one module to represent one ADT. I have seen examples of modules ]>containing several abstractions, as well as modules inside of modules and I ]>have yet to see what is gained by doing this; I do see what is lost : I cannot ]>not use one of the Abstractions without the others. I see an abstraction as ]>just that, a functional model of data and behavior and as such I want to ]>put it as a library unit. ]> ]>I would like to see examples where the packaging of several abstractions, or ]>the nesting of modules is a proper abstraction modelling. There are numerous occasions when what one is constructing is an abstraction of sufficient complexity that it requires "helper" sub- abstractions. There is no reason to assume that such sub-abstractions have any use outside the immediate implementation: in cases where this is true, placing such sub-abstractions in the library serves no useful purpose, pollutes the namespace, and, in fact, somewhat unbundles the main abstraction being implemented. In such cases, nesting the sub- abstractions inside the main abstraction is clearly a superior approach. Believing that there is necessarily a one-to-one correspondence between abstractions of interest to clients and modules strikes me as simplistic, particularly since the experiences of myself and of numerous customers indicate that this tends often to not be the case. -- * "Beyond 100,000 lines of code, you should probably be coding in Ada." * * - P.J. Plauger, Convener and Secretary of the ANSI C Committee * * * * The opinions expressed herein are my own. *