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

[rmartin@oma.com (Robert C. Martin)]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 5988 bytes --]


In article <32E8DC1C.4871@rase.com>, tansel@rase.com wrote:

> Contrary to what people say, type checking is against the nature of
> object oriented systems development. Remember, in OO, we only care about
> the interface of the other object. 

This statement is oxymoronic.  A type is defined by the interfaces it
accepts.  There is no other definition of a type.  Thus, the statement 
above could be translated as follows:

"...type checking is against the nature of OO...in OO we conly care about
the type of the other object."

In fact, type checking is at the very *heart* of OO.  The current debate
has nothing to do with whether types ought to be checked or not, indeed they
*must* be checked.  The current debate is simply arguing about *when* those
types will be checked.

In ST, users send messages to objects.  They must be reasonably sure that
the object they are sending the message to can respond to that message.  So
they are performing the type checking in their head.  The language performs the
same check later on, at run time.

In C++, the compiler insists that all types are declared, so that when
a programmer sends a message to an object, the compiler can be 100% certain
that the object can accept that message.  Thus, no run time check is 
necessary.

> In fact it should be an OO sin to ask
> the type, because, in theory, we don�t want to get intimate with objects
> we are interacting apart from their interface. 

We typically don't have to ask the type of an object.  In ST, the language
will do the asking for us at run time.  In C++ the compiler has done it 
at compile time.

However, there are times both in ST and C++ where we are given an object
of unknown type and we do not want to send that object a message until
we *know* it can deal with it.  Thus in ST we use 'respondsTo' and in
C++ we use 'dynamic_cast'.  Both of these are essentially run time type
checks that can be applied by the programmer.

> We only want to know the interface. 

Which *is* the type.  However, in ST we are interested only in a subset
of the interface; thus we are interested only in that portion of the 'type'
that responds to our message.  In C++ we approximate this ability to be
interested in partial types by using MI and creating true partial types.
(i.e. supertypes that declare only part of a particular subtype)  This
is why MI is not important to ST, but is critical to C++.

> one obvious solution that
> comes to mind is to offer an interface signature, that will indicate
> that an object really offers all the services that it is required. This
> will guarantee that type of the object can change any time as long as
> the public interface signature of the object does not change. Then any
> object binding to this object can ask its signature rather than type to
> verify that
> the interface is the same as this object was created. This has run time
> costs associated with it, but solves many problems that are associated
> with type checking. Furthermore it is not practical for many ADT based
> languages.  

In fact it is identical to dynamic_cast in C++ where the public interface
that you mentioned is an abstract superclass of the object being checked.
Java has a similar mechanism (isInstanceOf) and so does Eiffel (=?).  

> In most ADT based languages type checking is done at the compile time.
> This approach gives us a lot of safety, but also has an expensive price
> tag in terms of flexibility and compromise of object oriented approach.

No, the cost is not in flexibility.  The cost is in the time required
to declare all the types and manage the dependencies appropriately.
Flexibility is not encroached upon. 

The development time argument is a strong one.  The declaration of 
all types is somewhat onerous.  Java helps this out by building
the declarations into the implementations, but the dependency management
issues is still present.  In ST, declarations and dependency management are 
much less of a concern since all declarations are implied and none are checked
until runtime.

On the other hand, the benefit of static languages is in the fact that
they can be made very run time efficient, by doing all the type checking
at compile time.  Morevoer, once compiled we *know* that there are no
type errors lurking in the runnable code.  (Unless purposely put
there by casts).

> There can not be much done to increase flexibility of such languages.
> One of my solutions for flexible systems such as Smalltalk is, to use
> high level tools to automatically embed type or interface checking code
> in development and testing phase, and after all tests are done, to
> remove these checks automatically, allowing systems to run without type
> checking once they are in production. This gives me best of the both
> worlds."

Actually it give the worst of both worlds.  The lack of type checking is
of benefit only during development.  Once the program is known to work,
type checking is useless.  By putting a type-checker in front of the 
Smalltalk compiler (i.e. stlint ;^) you effectively introduce all the
disadvantages of C++ declarations and dependency management without providing
the benefit of efficient execution.  Once you remove the stlint, the run
time system is still doing run-time type checking (i.e. looking up method
invocations)

> Eighth: Performance. Actually this is a non-issue. I never suffered from
> performance apart from screen drawing, or number crunching. 

In most cases ST preformance *is* a non-issue.  But there is a large class
of applications that require hard real time performance, and which will
not be able to tolerate ST.

-- 
Robert C. Martin    | Design Consulting   | Training courses offered:
Object Mentor       | rmartin@oma.com     |   Object Oriented Design
14619 N Somerset Cr | Tel: (847) 918-1004 |   C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com  

"One of the great commandments of science is:
    'Mistrust arguments from authority.'" -- Carl Sagan