[erlang-questions] OOP in Erlang

[Richard O'Keefe]

On Aug 11, 2010, at 11:04 PM, Ed Keith 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.

And other teachers taught other students different slogans.
I was taught that the defining characteristics of an object
were "identity, state, and behaviour" and if a language had
objects it was an OO language.

This is arguing over terminology; I hope we can move past that to
argue about semantics.  It fundamentally doesn't MATTER whether something
is CALLED Object-Oriented or not.

Take Ada 95, for example.  It has encapsulation (associated with
modules, not classes), abstraction (associated with generics, not
classes), inheritance (associated with classes), and two kinds of
polymorphism (parametric polymorphism via generics and inheritance
polymorphism via classes).   Does the fact that classes per se
are NOT encapsulated mean that it isn't OO?  Ada encapsulation is
actually pretty good, and not only can be used to encapsulate
class information, but normally is.  But it's not OBJECT-based
encapsulation.  Oh yes, I lied when I said "classes".  Ada "methods"
are defined *outside* the hierarchically structured types, not inside.
Doesn't matter.

Who cares what we call it?  If you want to program in an OO style,
Ada 95 is perfectly adequate for the job.

If any language is an OO language, surely Smalltalk 80 is.  In normal
use, it's well encapsulated, but thanks to its introspection
facilities, that encapsulation amounts to "as long as nobody really
REALLY wants to poke their finger through the tissue paper."
Anyone who said *the* classic OO language wasn't really OO would be
laughed at.  For that matter, anyone who pointed out that because
you can cast any pointer to char* and thus scribble on anything,
C++ doesn't really have any *trustworthy* encapsulation to speak of,
C++ cannot be OO either, would get some strange and some hostile
looks.  I don't suppose Brad Cox would be too pleased to be told
that Objective C wasn't really OO either.

The question for Erlang is not "OOP in Erlang", but "what ideas
can we steal from _any_ other source that would be useful
_for Erlang_."  And for any such idea, "what exactly are we
proposing that Erlang should salvage from the other language,
in what form, and why do we need it?"