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

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

Xref: sparky comp.lang.c++:19957 comp.object:5071
Path: sparky!uunet!gatech!darwin.sura.net!paladin.american.edu!howland.reston.ans.net!spool.mu.edu!olivea!pagesat!spssig.spss.com!uchinews!alex!dave
From: [e-mail] (Dave Griffith)
Newsgroups: comp.lang.c++,comp.object
Subject: Re: Pros and cons of C++
Message-ID: <[e-mail]>
Date: 26 Jan 93 14:54:54 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail] (News System)
Organization: University of Chicago
Lines: 100

In article <[e-mail]> [e-mail] (Samantha Atkins) writes:
>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.
>

No question, better tools for this sort of thing are clearly needed.  A lot
of the problem is that it is tough to reconcile the needs of being able to
dynamically restructure the heirarchy with the needs of separate compilation.
We'll probably have to go to some sort of managed incremental compilation
regime to get the effects you want.

>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?
>

I'm not sure what you mean by message based checking.  If you just mean that
every reciever of a message is gauranteed to respond to the message we are
sending, with the arguments given it, such languages do exist.  Eiffel is
one, and even C++ will act this way if you don't try to fool the type checker.
Semantic checks are rare, but can also be had (runtime, not compile-time).

As to the problem with mixins, the problem exists, but it is not with
strong typing per se.  It is with the current fashion of conflating the
type heirarchy and the class heirarchy.  There is no reason, particularly,
that all of your little mixins need to be full fledged types.  There is no
reason to declare a variable to be of one of those mixin's, for instance.
Many of them will be just different (possibly partial) implementations of
certain types (protocol might be a better word here, type is dreadfully
overloaded in language discussions).  What I want to see, is a language
where protocols and implementations are definable independently.  Protocols
may for a heirarchy by subtyping, implementations form a heirarchy by
inheritance.  Inheritance can thus be just a form of code-sharing, possibly
not the only such form in the language.  There will no longer be as much
danger of "spaghetti inheritance" because the chief danger of using inheritance
for code-sharing, namely corruption of the subtype heirarchy, will be gone.
Factoring based on implementation will no longer conflict with factoring on
protocol, and the exponential mess you describe will just disappear.  Types
may have more than one implementation, and implementations may fulfill more
than one type.

(For my fans, Rorschach has precisely this sort of type system.)

Strong typing is certainly necessary, as it seems to cut down debug time and
system integration time and increase runtime safety.  It is also the case
that type systems to date have been far too inflexible, requiring workarounds
to acheive the desired program semantics at reasonable efficiency.  These
workarounds damaged the integrity of the type system, and added to language
complexity.  It is my belief that strong behavior-based type systems might
solved this problem, as strong structure-based type systems (C (if you don't
cheat), Ada, ML) seem not up to it.

--
Dave Griffith, Information Resources, University of Chicago,
Department of Surgery                       [e-mail]
When buying and selling are controlled by legislation, the first things bought
and sold are legislators.