OOP in Erlang

[Steve Davis]

On Aug 11, 6:04 am, Ed Keith <e_...@REDACTED> wrote:
> When I first studied OOP, in 1990, I was taught that OO was defined by four features: Encapsulation, Abstraction, Inheritance, and Polymorphism. That if any of these were missing it was not OO.
>
>       -EdK

I was taught this also. However, I'm pretty certain that Alan Kay
doesn't subscribe to this definition. Java-style OOP, of course, does.

Let's not ignore what java objects are. Instances of user-defined
types that are bundled with a number of transformations (methods) that
are legal (hopefully) on that type.

Looking at this another way, there's really only two things going on
here:
1) Data structures and
2) Transformations of data structures.

The class type definition defines a data structure, often as a
composite of other, previously defined structures. "Encapsulation"
insulates you from this detail. Thus you can program in a world at a
higher level, and that world of "Abstraction" was defined by one or
more programmers each with a different view of correctness and
applicability. So you'd better hope that all the detail of the
implementation was appropriate and well thought through. Of course it
usually isn't entirely appropriate to *your* problem and *your*
current notion of applicability...

...but never mind along comes a toolset to change all
that."Inheritance" will allow you to add to or modify the underlying
data structure and define or redefine the applicable transformations.
You can re-invent your abstraction as you please.  Obviously, you are
taking care to make sure everything is correct and applicable to the
problem domain (at least, the one you are currently aware of). Any mis-
step in this process has ramifications way beyond what you can
currently appreciate, when other programmers program in the world of
your new abstractions, along with any other issues inherited by it.

While you are making this wonderful re-useable software by extension
of other data structures and transformations you can do some radical
things to fix up problems of the past. Overloading, to allow you to
parameterize your transformations with other structures that may
impact the transformation of the subject of the transformation. With
overriding, you can just redefine the entire transformation.

Somehow you want to allow all these (different) types to continue to
be used with this new transformations, so you need type
"Polymorphism". You are careful to be sure that your new
transformation (method) will be applicable and correct for all data
structures that could be represented by the polymorphic type
(interface), so I guess you really need to know quite a bit about the
abstracted and encapsulated data structures so that your system
doesn't end up in an illegal state of some kind. Of course when you
don't know what type to use, just can just shove in a 'null'.

Having built your beautiful cathedral of types and transformations,
you may then need to define and implement a protocol to send it as
binaries over the network. To conform to the contract of the protocol,
you'll need to account for all that hidden state and implicit
transformations of it to keep the system consistent.

So... does OOP (Java-style) sound complicated and hard to manage? It
is. You are usually dealing with in a language of type definitions,
invented by all the programmers who touched the code, each with
different motivations, and which you do not (and probably cannot)
fully understand. You have lost the ability to reason effectively
about your program and your system.

/s