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

[Alan Lovejoy <alovejoy@concentric.net>]

Marc Robertson wrote:
> 
> Alan Lovejoy wrote:
> >
> > Graham Hughes wrote:
> > >
> [snip]
> >
> > > If OO is about conceptual separation of code into independent modules,
> > > why should the modules be concerned about what somebody else gives them?
> > > Why should they manually check that the object is capable of the
> > > operations demanded when the compiler can?
> >
> > This is a non argument.  Since someone must check, there is no difference in
> > principle whether that someone is the compiler or the run-time system.  It's
> > an implemenation difference, not a difference in kind.
> 
> There is a difference in practice.  If the compiler detects an error,
> the only one that has to worry about it is the developer.  If an error
> is present that the run-time system has to handle, all users are
> potentially affected by it.  There have been any number of studies(
> unfortunately, I don't have access to them here, so I can't quote them )
> that indicate that the cost to correct a problem increases dramatically
> the later in the development process you detect it. The sooner problems
> can be eliminated, the less it costs to eliminate them!

You and everyone else who replied to me completely misinterpreted the point of
the argument.

The issue I was addressing was not: "Is there any difference whatsoever between
dynamic and static typing."  Yet that is the question assumed by all the responses.
Bullshit: you can all take points off for answering the wrong question.

The ISSUE was: "Is dynamic typing contrary to OO design principles because the
object checks the type at runtime instead of relying on the compiler?".  Graham
Hughes was making an argument about the proper assignment of responsibility for
type checking from an OOA/OOD perspective, NOT from a software engineering/safety
perspective.  

And a strong case can be made that having the compiler check based on "types"
(actually type constraints/assertions) assigned to variables (not objects) 
is a severe violation of the information hiding principle.  An object should
ideally be a black box that hides its implementation (class).  Exposing the
interface of the object is acceptable, even good.  But most statically-typed
OO languages go beyond that into exposing the implementation (class)--and then
hard coding it into type constraints on variables in the program source, which 
is very, very bad.  

Using the class as a substitute for the interface violates the information hiding
principle.  This was and is the issue.

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