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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,3d3f20d31be1c33a X-Google-Attributes: gid103376,public X-Google-Thread: f43e6,2c6139ce13be9980 X-Google-Attributes: gidf43e6,public X-Google-Thread: fac41,2c6139ce13be9980 X-Google-Attributes: gidfac41,public X-Google-Thread: 1108a1,2c6139ce13be9980 X-Google-Attributes: gid1108a1,public From: Graham Perkins Subject: Libraries in pure OO [was Interface/Implementation (was Re: Design by Contract)] Date: 1997/09/16 Message-ID: <341EB0A2.131F@dmu.ac.uk>#1/1 X-Deja-AN: 273130612 References: <5vkfb2$f2p$2@trumpet.uni-mannheim.de> Organization: De Montfort University Milton Keynes Reply-To: gperkins@dmu.ac.uk Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel Date: 1997-09-16T00:00:00+00:00 List-Id: .. hope thread renaming helps rather than hinders. How to get normal library effect from OO language? Especially pure one such as Eiffel where there are no modules (ie, "static" bits of the classes). IMHO two very important things about libraries, regardless of whether you try to provide them with modules, classes, or whatever: (1) Use the library in client mode (because library designer hid stuff in order to reduce coupling and allow evolution). (2) System should have a single instance of the library (because multiple instances would simply waste space/time as they're indistinguishable). Modular languages ----------------- You can easily get both effects 1 and 2 above because a module (unit, package, whatever you call it) has precisely those properties. Hybrid languages ---------------- You can easily get both effects in hybrid languages such as C++, Java, Smalltalk ;-)) since class doubles up as module. (part of class generates 0,1, or more runtime instances but another part of the class describes a single runtime instance). Though to ensure (1) you should disallow creation methods in your library class. Pure class languages -------------------- You don't have a module or a class-which-is -also-a-module, but you still have ability to program in client-supplier mode and create single system-wide instances. So you can still ensure properties (1) and (2). In Eiffel: a) put a once function in ANY (remember that ANY is a good place to put your per-project stuff). b) define an anthropomorphic class (eg MATHEMATICIAN) which provides access to library via once function. Make sure library creation method is only visible to this accessor class. These alternatives can be implemented in other languages without much difficulty. -------------------------- what about feature math : expanded BASIC_ROUTINES ... x := math.sqrt( y ) Yes I know it was rather neat to put expanded library object wherever you want it, but that relied on - constructed value objects (bye bye Java and Smalltalk) - static binding for value objects (can't be sure in C++) - no attributes at all in the class The last point in particular is a problem, since it means that the client programmer is taking advantage of internals of the class. Which isn't safe clientship in my view. Sorry if I'm stating the obvious, but I hadn't seen anyone explaining an implementation approach in terms of usability principles such as (1) and (2) above.