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

[Alan Lovejoy <alovejoy@concentric.net>]

Matt Kennel wrote:
> 
> Alan Lovejoy (alovejoy@concentric.net) wrote:
> 
> : 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.
> 
> 1) Why is this very very bad?  Why is it non-very bad?

Because it fails to separate interface from implementation.

> 2) The type constraints on variables do not necessarily prescribe any
>    particular concrete class, much less expose any internal class information
>    to extra manipulation.  What is the relation to "information hiding"?  The
>    inside-vs-outside encapsulation generated by Eiffel classes or Ada packages
>    or M3 modules has no relation to type constraints on variables, as far
>    as I can see.

I thought I made it clear that I was specifically deprecating those languages
that use **classes** as type constraints.  And I thought I made it clear that 
"Exposing the interface of the object is acceptable, even good."

And I agree that the way static typing is done in Ada, Modula-3 and Eiffel is
quite superior to what C++ does. But I would be even happier with the way Ada 
or Eiffel handle typing if one could simultaneously have two different variables 
whose static type constraint is "Dictionary" but where each is actually an instance 
of a different class (say HashTable and BinaryTree)--and the only class they both 
have in common in their inheritance hierarchy is Object.

> : Using the class as a substitute for the interface violates the information hiding
> : principle.  This was and is the issue.
> 
> 3) And suppose you actually want to specify a particular concrete class?
>    You have [to] "hard code" classes to create instances, after all.

	VAR

		dictionary1, dictionary2: Dictionary;

	BEGIN
	
		dictionary1 := new HashTable;
		dictionary2 := new BinaryTree;

Does that answer your questions?

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