Re: OO, C++, and something much better!

[Alan Lovejoy <alovejoy@concentric.net>]

Norman H. Cohen wrote:
> 
> Alan Lovejoy wrote:
> >
> > Matthew Heaney wrote:
> ...
> 
> > > Constraint_Error was raised because the range constraint was violated.
> > > This behavior is similar to the Eiffel behavior when a precondition is not
> > > satisfied.  The terms of the contract between the client (the caller) and
> > > server (the subprogram) were violated by the client, so an exception was
> > > raised.  Isn't that what you would expect to happen?
> >
> > Yep.  Just like what happens in a dynamically-typed language: a "message not
> > understood" exception is raised when an object with the wrong value is sent
> > a message it can't handle (the class of an object is part of its value in
> > a dynamically-typed language).
> 
> Or, to put it another way, the types of a dynamically typed language are
> like the subtypes (subsets of types defined by constraints checked at
> run time) of a statically typed language with one type.

The analogy can certainly be made (wether it's a perfect one or not is
another question--one which is probably not worth considering on USENET).

> The advantage of a statically typed language is that it enables the
> designer to divide the objects the program will be using into groups, so
> that those objects "understanding a particular message" are in the same
> group, to adopt the convention that certain variables will only be used
> for objects in a certain group, and to send messages only to objects in
> groups that are known to understand them--and to have the compiler
> enforce these conventions and catch errors before a program is ever
> executed.  (In a strongly-typed language with class-based polymprohism,
> these groups need not be disjoint, but instead may be nested.)

Static typing has both advantages and disadvantages with respect to dynamic
typing.   The question is which is better in particular circimstances.

There is some execution speed penalty for dynamic typing, so that may rule
out its use.  Program correctness may be so much more critical than development
time--and the product is not in danger of being shipped when some deadline
occurs, whether it's ready or not--that static typing would clearly be the
preferred approach.

> There is ample evidence that errors caught at compile time are less
> costly to identify and eliminate than errors caught only when a certain
> point is reached in execution.  Furthermore, the greater the number of
> errors that are caught independent of any particular execution path
> being taken, the smaller the number of errors that will be present in a
> delivered product.

Sure.  Everyone agrees that catching errors at compile time is less costly.

However, dynamic typing results in signficantly faster development time.
So as long as the number of typing errors that occur in practice are low
enough, dynamic typing is still a net win.  In my experience, the frequency
of occurrence of such errors is about 2% of all errors--which is much lower
than the break-even point.

--
Alan L. Lovejoy		|==============================================| 
Smalltalk Consultant	|	Beware of Geeks bearing GIFs!	       |
alovejoy@concentric.net |==============================================|