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

Internet Message Format | 1993-01-26 | 3.4 KB

Xref: sparky comp.lang.c++:19906 comp.object:5058
Newsgroups: comp.lang.c++,comp.object
Path: sparky!uunet!portal!samantha
From: [e-mail] (Samantha Atkins)
Subject: Re: Pros and cons of C++
Message-ID: <[e-mail]>
Sender: [e-mail]
Nntp-Posting-Host: jobe
Organization: Portal Communications Company -- 408/973-9111 (voice) 408/973-8091 (data)
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 26 Jan 1993 07:15:03 GMT
Lines: 54

In article <[e-mail]> [e-mail] writes:
>In article <[e-mail]> [e-mail] (Craig Shaver) writes:
>
>   We have been fed strong type checking for some time via Nick Wirth and
>   the original pascal teaching language.  This led to ADA which is still-born
>   in the commercial world.
>
>Pascal's, Ada's, and C's type systems are quite antiquated. Many
>modern "strong" type checkers (static type checkers) are very
>expressive and flexible; for much of the code written for such type
>checkers, you wouldn't even be able to tell whether the code is
>statically or dynamically typed.
>
>                    Thomas.

Hmmmm.  It seems to me that a couple of problems exist with all the static
type languages (compile time checking) that I am familiar with.

The first problem is that such languages require recompilation of any and
all affected code whenever the type hierarchy is reworked even if this
results in no changes at all to the behavior of any objects in the application.
In practice for larger projects this is an unholy terror.  I may be wrong
but I thought that one of the blessings of OO was being able to refine a
design even with working code in the field with little or no impact.

The second problem is related in that most such languages use type based
checking.  It seems to me that what we are really concerned with is:
    a) does this object understand the message we are sending?
    b) does its behavior conform to what we intended in response?
No object language I am aware of does a message based much less a decent
semantic based check.  So in what way has safety been assured really?
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.  Then for working classes I would mix and match to
produce just what I 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.

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?

Comments?

Samantha Atkins
Object Enterprises