[erlang-questions] OOP in Erlang

[Michael Truog]

On 08/11/2010 07:49 PM, Richard O'Keefe wrote:
> On Aug 11, 2010, at 7:44 PM, 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 was recently reading a collection of essays by Kent Beck, one of the
> big names in the Smalltalk and Patterns worlds.  Oddly enough, he said
> that he didn't think inheritance was all that big a deal.
>   

I agree that inheritance can be more trouble than it is worth in large
systems.  A good example is the Microsoft Foundation Classes which were
replaced by .NET (i.e., if MFC was great, it would not need to be
rewritten).  Has-A relationships are much easier to understand with
proper scoping than Is-A relationships.  The most useful book I have
found for designing large systems that are maintainable is "Large Scale
C++" by Lakos
(http://www.amazon.com/Large-Scale-Software-Design-John-Lakos/dp/0201633620). 
However, these types of design issues are much easier to find in C++
than in Erlang, since you can accomplish more with less source code
(i.e., smaller systems when judging by a non-whitespace line count) in
Erlang (and Erlang does not provide inheritance, but rather has the
simpler concept of behaviours).

A common mistake that is easy to make in C++ is to have a small fine
grained type of object that is abstract (only virtual methods) with a
very large vertical inheritance hierarchy of perhaps 5 or more levels. 
I think such object hierarchies make the system less scalable because of
the virtual function calls with extreme runtime polymorphism.  Usually
source code that is written like this was over-engineered and only
exists to waste both development-time and run-time.

Erlang would not benefit from the added complexity of OOP inheritance.