Re: Real OO

[dewar@cs.nyu.edu (Robert Dewar)]

Don Harrison said

> :Simply this:  Classwide operations can be defined anywhere by anyone.
> :They do not have to be defined along with the primitive types in
> :their packages.

> In OO software, you would want to define them with their types
> (except that in Eiffel, you assign the operation to a particular
> type - whichever is most appropriate). Otherwise, you would end up
> with spaghetti, IMO.

It's always surprising how people get carried away with one narrow view
of programming paradigms. It very much reminds me of the old saying that
"if the only tool you have is a hammer, then all problems start to
resemble nails".

The idea that you should package operations with types is a very useful
(and very old one). The particular enbodiment that we refer to as object
oriented programming is in particular a very useful (and also very old)
idea.

But going one step further and saying that this idea is so effective that
ALL software must be organized this way, and that any other organization
is defective is simply not justified.

As I say, this seems a common affliction in the programming languages
field:

   o  Functional programming is very useful, but disallowing notions of
      implicit state completely seems to be going much too far.

   o  Proof of correctness is very useful, but insisting that programming
      languages be designed so that only programs with integral proofs
      can be written seems to be going much too far.

   o  Strong typing is very useful, but insisting that separate types be
      used for every separate notion, no matter on how small a scale, is
      going too far.

   o  Top-down structured design is very useful, but insisting that ALL
      programs use only this design approach is going too far.

   etc.

To me the "pure" OO view that Don expresses is yet another example of this
excess of zeal.

There are many instances in which it makes sense to package operations
by classifying operations, rather than types. For example, It seems quite
appropriate to have a set of procedures for matrix diagonalization packaged
up together, rather than bundled in with the matrix type (indeed the idea
of bundling all possible matrix operatoins up with the matrix type is 
untenable). Similarly, it makes sense to have trig functions for various
floating-point types bundled up in a package, rather than scattered around.

The world of operations and types can be though of as a matrix:

      type 1    type 2   type 3 ...

 op1    x          -        x
 op2    -          x        -
 op3    x          x        -
 ...

Roughtly speaking, the OO approach organizes by columns, which is often
fine, but the operation organization by rows also often makes sense.
For example, if op3 represents some complex numerical procedures,
understood only by a small group of experts, it may well be better
to bundle up op3 rather than distributing the op3 code around the
separate types.

A maximally effective programming language will be friendly to either the
"row" view or the "column" view, or flexible mixtures of the two.

P.S. spaghetti code doesn't just mean code you don't like. It is a rather
specific term used to described the non-nested chaotic control structures
caused by undisciplined use of gotos or equivalent transfers of control.
I think it is useful to keep this sense.