Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!pacbell.com!ucsd!hub.ucsb.edu!eiffel!bertrand From: bertrand@eiffel.UUCP (Bertrand Meyer) Newsgroups: comp.lang.eiffel Subject: Re: Three ways to use library-like classes Keywords: library constants Message-ID: <562@eiffel.UUCP> Date: 30 Apr 91 23:55:31 GMT References: <1991Apr30.140340.25415@bony1.bony.com> Organization: Interactive Software Engineering, Santa Barbara CA Lines: 50 From <1991Apr30.140340.25415@bony1.bony.com> by richieb@bony1.bony.com (Richard Bielak): > I have seen two different ways of using classes that are > "library-like" (I mean classes like SINGLE_MATH, which only contain > various math routines, or classes that only define constants). I > thought of a third way to use these, that seems (to me anyway) a > little cleaner. Here are the three ways, I'll use SINGLE_MATH as an example: > 1) Inherit > > class COMPLEX is > inherit > SINGLE_MATH > feature > [...] > end; -- COMPLEX > > I don't like this method, since a COMPLEX number *is not* a > SINGLE_MATH library. [Others omitted] What about the following justification for technique 1, using inheritance? The abstraction described by SINGLE_MATH is not ``a SINGLE_MATH library'', which is not a run-time notion anyway, but something like ``Objects which have access to SINGLE_MATH operations'' in the same way that the abstraction described by STACK is ``objects on which the STACK operations are applicable'', and so on for other notions. Then the ``is'' relation is justified: classes which are descendants of SINGLE_MATH indeed describe objects which, among their other properties, have those of SINGLE_MATH, as expressed above. Although this may seem a bit far-fetched, it makes some sense - at least I believe so. -- -- Bertrand Meyer Interactive Software Engineering Inc., Santa Barbara bertrand@eiffel.uucp -- -- Bertrand Meyer Interactive Software Engineering Inc., Santa Barbara bertrand@eiffel.uucp