🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.lang.misc
Article #4625

Re: Object-Oriented vs. Abstract Data Types

#4625
From: rentsch
Date: Sun, 25 Jan 1987 08:22
51 lines
3094 bytes
> > > [...] Basically, the only reason *not* to
> > > have dynamic binding is the belief that "it costs too much".

> > Not so.  Another reason to avoid dynamic binding is that doing so
> > makes it easier to catch certain programming errors early on.
> > The earlier an error is caught, the less damage it does.

> This is the part that troubles me most about run-time error checking.
> In order for an error to be noticed at run time, the program thread
> containing the error has to be executed.  This may not happen until
> the program had been out in the field for many months (or years...).
> The only way to test for such errors it to have a test suite that
> executes every single branch in the software.

(I talked about this in the original article, but apparently not
clearly enough.  Let me try again.)

The '> > ' poster seems to assume that dynamic binding implies
certain errors (usually called "type errors") can only be caught at
runtime.  Not so.  

Systems with dynamic binding usually also include run-time checking.
But, dynamic binding need not *require* run-time type checking.  

For example, Smalltalk-80 does require run-time type checking.  But,
if type declarations are added, the same language (and with the same
interpreter) can be staticly typed and staticly type checked.  When
this is done, run-time type errors (e.g., "message not understood",
etc.)  cannot occur.  For those interested, this has actually been
done -- it was reported in POPL 1982.  

Note that having compile-time typing and type checking does not
remove the need for dynamic binding.  A polymorphic type (e.g.,
"'Stream' - like") argument does not require the same procedure for
each actual argument, just arguments that supply the right methods.
But which method gets invoked must still be looked up at run-time.

Predicating his article on the run-time error checking assumption,
the '> ' poster raises a valid point.  On the other hand, isn't it
common practice in software engineering to require execution of all
software paths in test cases before releasing the product?  (To be
fair to the other point of view I will say that even this is not
enough to guarantee no run-time errors -- to do that every
COMBINATION of paths would have to be executed, which is not done in
general, nor should it be.  I am not trying to argue with his point,
just make a side comment, and more importantly point out that his
assumption is only an assumption.)  

cheers,

Tim
Technical Details
Message-ID: <703@unc.unc.UUCP>
Path: arc1-ca.pugleaf.net!utzoo!watmath!clyde!rutgers!princeton!allegra!ulysses!gatech!mcnc!unc!rentsch
References: <1023@cuuxb.UUCP> <4000003@nucsrl.UUCP>

Show Full Headers
Complete Article Headers
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: arc1-ca.pugleaf.net!utzoo!watmath!clyde!rutgers!princeton!allegra!ulysses!gatech!mcnc!unc!rentsch
From: rentsch@unc.UUCP
Newsgroups: comp.lang.misc
Subject: Re: Object-Oriented vs. Abstract Data Types
Message-ID: <703@unc.unc.UUCP>
Date: Sun, 25-Jan-87 03:22:08 EST
Article-I.D.: unc.703
Posted: Sun Jan 25 03:22:08 1987
Date-Received: Thu, 29-Jan-87 03:18:09 EST
References: <1023@cuuxb.UUCP> <4000003@nucsrl.UUCP>
Reply-To: rentsch@unc.UUCP (Tim Rentsch)
Organization: CS Dept, U. of N. Carolina, Chapel Hill
Lines: 51