Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!crdgw1!uunet!mcsun!ukc!pyrltd!tetrauk!rick
From: rick@tetrauk.UUCP (Rick Jones)
Newsgroups: comp.lang.eiffel
Subject: Re: Three ways to use library-like classes
Keywords: library constants
Message-ID: <1148@tetrauk.UUCP>
Date: 1 May 91 09:14:18 GMT
References: <1991Apr30.140340.25415@bony1.bony.com>
Reply-To: rick@tetrauk.UUCP (Rick Jones)
Organization: Tetra Ltd., Maidenhead, UK
Lines: 51

In article <1991Apr30.140340.25415@bony1.bony.com> richieb@bony1.UUCP (Richard Bielak) writes:
>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:
>
> [ three examples deleted ]

There is a fourth way:

4) Constant Attribute

        class COMPLEX is

        feature
                mlib : SINGLE_MATH is once Result.Create end;
                [...]
        end; -- COMPLEX

Here you don't have to explicitly create SINGLE_MATH, only one object exists,
and it doesn't occupy any space in the COMPLEX object.

I agree to some extent with the objection to example (1) - inheriting from
SINGLE_MATH - because the implied is-a relationship is not really true.
However, Eiffel version 3 will allow something like (this syntax may not be
quite right):

        class COMPLEX is
        inherit
                SINGLE_MATH
			export {NONE}
		end
        feature
                [...]
        end; -- COMPLEX

This explicitly says that none of the exported features of SINGLE_MATH are to
be exported by COMPLEX.  The implied meaning is that COMPLEX is not a sub-type
of SINGLE_MATH.  (The type system should be able to do something smart with
that!)

I would tend to use this in practice, mainly for syntactic simplicity and
efficiency.  I have often wondered about the merit of having an "include"
clause in Eiffel, meaning "inherit but not as a sub-type";  this would be
semantically identical to the example above, but perhaps expressively clearer.
-- 
Rick Jones, Tetra Ltd.  Maidenhead, Berks, UK
rick@tetrauk.uucp

Any fool can provide a solution - the problem is to understand the problem