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

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

Xref: sparky comp.lang.c++:20098 comp.object:5118
Newsgroups: comp.lang.c++,comp.object
Path: sparky!uunet!mole-end!mat
From: [e-mail]
Subject: Re: Pros and cons of C++
Message-ID: <[e-mail]>
Summary: When to recompile ...
Organization: :
References: <[e-mail]> <[e-mail]>
Date: Tue, 26 Jan 1993 18:42:08 GMT
Lines: 64

In article <[e-mail]>, [e-mail] (Samantha Atkins) writes:

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

Depends what you mean by `affected code.'  If I have code which takes a
parameter of type  X  and I derive  X1  and  X2  from  X , I can use that
code on  X1  and  X2  without recompiling it.  On the other hand, if I
change the definition of  X , then I do have to recompile.

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

Impact to _what_?

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

You pay a price for every bit of flexibility you have.  If I have an
 int  instead of a  const int  in code, I am just a bit less certain that
that object's value is what it was a statement ago.  The key is determining
the kinds of flexibility that you need and the kinds you don't, and paying
only for what you need.  OO is not a silver bullet, just another stall in
the marketplace.

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

If you don't know what you want, then strong typing isn't for you.

But if you can make reasonable engineering judgements about the places
where you will need flexibility and the places where you can do with
less flexibility, you can shape your design for maximum re-use of the
design.  Re-use of code will follow.

In a way this is like the discussion of non-virtual functions in base
classes: they make all the sense in the world if you can define for
your type things which will be invariant across its entire derived class
hierarchy.  If you need complete flexibility, of course, you use an
abstract base with all pure virtual functions.  In practice, you _want_
to limit flexibility to just those places that need it to reduce the
cost in uncertainty paid by the fellow reading and re-using the code.

These are engineering decisions, not matters of doctrine and heresy.
--
 (This man's opinions are his own.)
 From mole-end                Mark Terribile

 [e-mail], Somewhere in Matawan, NJ