richieb@bony1.bony.com (Richard Bielak) (04/30/91)
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.
2) Attribute
class COMPLEX is
feature
mlib : SINGLE_MATH;
[...]
end; -- COMPLEX
Here any reference to a routine in SINGLE_MATH would be
"mlib.something". This is a little better than (1), however
"mlib" has to be Created before any calls will work.
I don't like having to do the Create.
3) Expanded attribute (my way :-)
class COMPLEX is
feature
mlib: expanded SINGLE_MATH;
[...]
end; -- COMPLEX
Now I can can make calls "mlib.whatever" without having to do
a Create on "mlib".
It works. What do you think?
...richie
--
*-----------------------------------------------------------------------------*
| Richie Bielak (212)-815-3072 | Programs are like baby squirrels. Once |
| Internet: richieb@bony.com | you pick one up and handle it, you can't |
| Bang: uunet!bony1!richieb | put it back. The mother won't feed it. |bertrand@eiffel.UUCP (Bertrand Meyer) (05/01/91)
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
rick@tetrauk.UUCP (Rick Jones) (05/01/91)
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
quarrie@cds001.cebaf.gov (David Quarrie) (05/01/91)
-- In article <1991Apr30.140340.25415@bony1.bony.com>, richieb@bony1.bony.com (Richard Bielak) writes: |>Path: |>murdoch!uvaarpa!haven.umd.edu!udel!wuarchive!uunet!bony1!richieb |>From: richieb@bony1.bony.com (Richard Bielak) |>Newsgroups: comp.lang.eiffel |>Subject: Three ways to use library-like classes |>Keywords: library constants |>Message-ID: <1991Apr30.140340.25415@bony1.bony.com> |>Date: 30 Apr 91 14:03:40 GMT |>Reply-To: richieb@bony1.UUCP (Richard Bielak) |>Organization: Bank of New York |>Lines: 57 |> [lines deleted] |> |>3) Expanded attribute (my way :-) |> |> class COMPLEX is |> feature |> mlib: expanded SINGLE_MATH; |> [...] |> end; -- COMPLEX |> |> Now I can can make calls "mlib.whatever" without having to do |> a Create on "mlib". |> |> |>It works. What do you think? |> |> |>...richie The method I've used, at least in situations where I want to use a class having lots of constant definitions, is something like the following class COMPLEX is feature mlib: SINGLE_MATH is once Result.Create end; -- mlib end; -- COMPLEX This might look like overkill for the situation where the class contains mainly constants, but it avoids exceeding the limit of 1000 features in an Eiffel class (which amazingly enough I have managed to exceed when using a class containing all the Motif constants), and by using a "once" routine, this attribute is shared by all objects of class COMPLEX, perhaps saving some space relative to Rithie's proposal. It also avoid having to explicitly "Create" the class. It does suffer some additional overhead though, especially when fetching constants from the "included" class. David Quarrie CEBAF (Continuous Electron Beam Accelerator Facility) quarrie@cds001.cebaf.gov
sommar@enea.se (Erland Sommarskog) (05/02/91)
Also sprach Richard Bielak (richieb@bony1.UUCP): >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 ... >2) Attribute ... >3) Expanded attribute (my way :-) Interesting. I have been thinking on this problem too. I don't like inheriting BASIC just because I need some routine from it. It opens for confusion for me with names coming out of nowhere. And people who inherit from me, may be surprised when BASIC is turning up where they don't expect. And my class uses BASIC, it is not a BASIC. I had in my mind a language change, adding a Library clause under which you would mention class which you referred to without objects directly through the class name. Now, Richard's idea with expanded attributes gives me this without a language change at the cost of an extra identifier. I think I can live with it. Thanks, Richard! -- Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.se Le fils du maire est en Normandie avec beaucoup de medecins.
jcm@mstr.hgc.edu (James McKim) (05/06/91)
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: > >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. Agreed. In addition, if we inherit from several of these, we risk we will almost certainly run into spurious name conflicts. > >2) Attribute > > class COMPLEX is > > feature > mlib : SINGLE_MATH; > [...] > end; -- COMPLEX > > Here any reference to a routine in SINGLE_MATH would be > "mlib.something". This is a little better than (1), however > "mlib" has to be Created before any calls will work. > > I don't like having to do the Create. Me either. Wastes a line of code, and at least a little space (the pointer to SINGLE_MATH). > >3) Expanded attribute (my way :-) > > class COMPLEX is > feature > mlib: expanded SINGLE_MATH; > [...] > end; -- COMPLEX > > Now I can can make calls "mlib.whatever" without having to do > a Create on "mlib". > > >It works. What do you think? > I like it! I have not used "expanded" before, but this _seems_ like a natural place! *------------------------------------------------------------------------------* Jim McKim (203)-548-2458 | _Give_ people fish and they eat for a day. Internet: jcm@mstr.hgc.edu | _Teach_ them to fish and they eat for a lifetime.