Re: Ammo-zilla

[Robert Dewar <robert_dewar@my-deja.com>]

In article
<Pine.BSF.4.10.9910311929570.12649-100000@shell5.ba.best.com>,
  Brian Rogoff <bpr@shell5.ba.best.com> wrote:
> Haskell doesn't support OOP, in particular, it doesn't support
> dynamic dispatch so I don't think the comaprison is
> appropriate.


I find it continually confusing that people confuse a
programming paradigm (OOP) with some features in the language
that are useful for supporting this paradigm.

The point is of course that dynamic dispatching, type extension,
and inheritance, are all generally useful features. They can
be used for many things, only one of which is object oriented
programming. In fact in my experience, the more common use is
simply in making more flexible, reusable abstract data types
(many people think they are doing OOP when they do this!)

The dot notation and distinguished receiver notions are indeed
useful when you are doing OOP, but they get in the way of many
other uses of these features (in particular, modeling a
dispatching addition operator in this way makes little sense,
but there are lots of other answers).

So the argument about notation is almost always off center,
since on the one hand you have people who are concerned with
one very specific use of the features, and on the other hand,
you have people who see these features as much more general.

The distinction between:

  Obj.Method1 (X);

and

  Method1 (Obj, X);

is basically a rather small syntactic distinction, and there is
no issue of loss of expressive power. But if we go entirely to
the first notation, then we will lose a lot of generality,
generality that will be sorely missed by those of us who use
these features all the time in non-OOP contexts.

Note in particular that object oriented programming is all about
objects which have state.

But the basic capabilities (type extension, inheritance, dynamic
dispatching) are equally (perhaps more) applicable to pure value
oriented programming using conventional abstract data types. In
this context, the notion of a distinguished receiver is a
distraction if you are just talking about computing an output
value from input values.

Of course this point has been made many times before, and by
many different people, in many different ways, but I have seen
nothing stated that would begin to contradict the most useful
viewpoint, as expressed above.


Sent via Deja.com http://www.deja.com/
Before you buy.