[erlang-questions] OOP in Erlang

Jesper Louis Andersen <>
Wed Aug 11 11:03:13 CEST 2010


On Wed, Aug 11, 2010 at 10:37 AM, Hynek Vychodil <> wrote:
> On Wed, Aug 11, 2010 at 9:44 AM, Guy Wiener <> wrote:
>> I have to stand up for OOP at this point: OOP does not start and end with
>> "encapsulating code and data". The OOP feature that has the strongest impact
>> on code brevity is *inheritance*. Thus, the interest in extending modules.
>
> I can't agree with you.

Me neither. To provoke: Inheritance (In Java/C++ style OO) has a
strong impact, but it is negative rather than positive. In my
experience, all languages with no inheritance features whatsoever beat
those with in brevity. In Erlang, whenever somebody thinks
inheritance, you should take a step back and think "closure" or
"higher order function". The whole concept of "Red car inherits from
car" does not work, save for introductory Java courses. So in
practice, inheritance is used to facilitate code reuse and composition
- and in my experience, functional programming tend to have much
better tools for composing code[1].

Another point is google Go, which has no inheritance per se, but uses
an interface concept: an object can belong to zero, one or many
interfaces by implementing the methods in that interface. The
declaration is implicit and inferred so the programmer is saved from
doing boilerplate notation. That is, interface implementation is
purely structural. "If you implement these methods with these types,
you are an implementor of the interface and can be used whenever the
interface is used." There is a way to embed all methods from one
object into another which gives somewhat the inheritance concept, but
it is subtly different. Structurally constructing the type hierarchy
is not new. Ocaml has had it for years.

Parameterized modules make me warm and fuzzy because they seem to give
a way to implement ML-style functors (maps from modules to modules).
It may look like an object, but I don't think it is. Module parameters
are static unless you jump hoops for instance.


[1] Erlang, even with a lack of currying, fares better here.


-- 
J.


More information about the erlang-questions mailing list