NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/lang/cplus/20002

Internet Message Format | 1993-01-28 | 3.1 KB

Xref: sparky comp.lang.c++:20002 comp.object:5083
Newsgroups: comp.lang.c++,comp.object
Path: sparky!uunet!charon.amdahl.com!amdahl!rtech!pacbell.com!ames!elroy.jpl.nasa.gov!sdd.hp.com!swrinde!emory!gatech!rpi!batcomputer!munnari.oz.au!metro!extro.ucc.su.OZ.AU!maxtal
From: [e-mail] (John MAX Skaller)
Subject: Re: Pros and cons of C++
Message-ID: <[e-mail]>
Sender: [e-mail]
Nntp-Posting-Host: extro.ucc.su.oz.au
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 27 Jan 1993 20:18:38 GMT
Lines: 52

In article <[e-mail]> [e-mail] (Samantha Atkins) writes:
>Only in that the type understands the message.  OK.  So if I want to get
>the maximum flexibility I would probably tend to factor my class hierarchy
>very highly with lots and lots of mix-in classes for every reasonable
>set of behaviors.

    Not every reasonable set: just some basic and fairly
independent sets to form the 'Axioms', and some common combinations
with additional computed functions : 'Theorems'.

>Then for working classes I would mix and match to
>produce just what I need.

    For your working Objects: each object a different mixin class
if you need.

>Here we run into some sticky situations in that
>not only would I need all these little mixins but I would also quite likely
>need various equally abstract classes that represent various combinations
>of them as my typing of say, parameters, is only class based and I want to
>leave maximum flexibility and reuse in.  Now it seems pretty obvious to me
>that over time I'm going to want to change this around or add more combinations
>as I can't just declare the whole exponential mess right the first time.
>Also we would have to contend with the unpleasant fact that all this churning
>through this exponentially growing hierarchy takes real CPU time and resources
>that eventually will get very seriously strained.

    I think its the other way around. WITHOUT mixins you have to
declare a whole lot of different classes to do what you might
want.

    WITH mixins you only need to declare the sorts of interfaces
you need at in the current program. The basic library functions
operate on the abstract bases of these classes.
>
>Am I going askew here or is it as it seems to me that so called strong typing
>creates an untenable mess if you seriously attempt its use now and for the
>future?

    Class based strong typing does have the disadvantage
that you have to make a class for every object, you cant just
make up the methods you need as you need them.

    Mixins are a sort of compromise between the two approaches:
use classes, but keep them small and independent. Get flexible
object construction AND strong typing.

--
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         [e-mail]
    Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;------ SCIENTIFIC AND ENGINEERING SOFTWARE ---ph:  2 799 8223 --------