NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/object/5101

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

Path: sparky!uunet!nwnexus!korona!pkron
From: [e-mail] (Peter Kron)
Newsgroups: comp.object
Subject: Re: Pros and cons of C++
Message-ID: <21.UUL1.3#[e-mail]>
Date: Thu, 28 Jan 93 10:51:24 PDT
References: <[e-mail]>
Organization: Corona Design, Inc., Seattle, WA
Reply-To: [e-mail]
Lines: 68

> From: [e-mail] (Samantha Atkins)
> Subject: Re: Pros and cons of C++
> Message-ID: <[e-mail]>
>
> [reference deleted]
>
> 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.

Exactly. Lots of work is going into environments to "protect" the
programmer from this impact, without realizing the flaw you have cited.
Even protected, the cost is large--complicated inclusion paths and
dependencies, increased debug-cycle/build times. These are still real
problems in real project environments.

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

I agree again. And if you don't get it right the first time you run afoul
of the first problem you cited--rebuilding everything. That discourages
making reasonable changes because of the cost involved. How are changes
due to natural evolution of products going to be handled? How do we
"rebuild the world" if it contains separate components made by different
companies? I am skeptical that compile-checked mix-in classes will be
able to handle it. Anyone know of a real-world success story?


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

You're not askew in my coordinate-space.

> Comments?
>
> Samantha Atkins
> Object Enterprises
---------------
Peter Kron                                          P.O. Box 51022
Corona Design, Inc.                         Seattle, WA 98115-1022
[e-mail]