On 19/09/2007, <b class="gmail_sendername">Dmitrii 'Mamut' Dimandt</b> <<a href="mailto:dmitriid@gmail.com">dmitriid@gmail.com</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">



  

<div bgcolor="#ffffff" text="#000000">
Toby DiPasquale wrote:<blockquote cite="http://mid876ef97a0709190431k2a3ca2e0rba149c6e79f23656@mail.gmail.com" type="cite"><span class="q"><pre>This would be in conflict with Joe's statements about Erlang not being<br>
object-oriented, right</pre></span>
</blockquote>
>From the TOC: <a href="http://erlang.org/erlang_book_toc.html" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://erlang.org/erlang_book_toc.html</a><br>
17   Object-Oriented Programming<br>
    17.1 Basic Concepts<br>
    17.2 Mapping to Erlang<br>
    17.3 An Object-Oriented Interface<br>
    17.4 Object-Oriented Programming<br>
    17.5 Object-Oriented Design<br>
<br>
I mostly interested in the "Mapping to Erlang" chapter as it could be
quite useful when trying to port certain libraries to Erlang</div></blockquote><div><br>Did you ever get a reply to this?<br><br>The method described was rather basic but it would have worked. In many ways it is similar to a gen_server but specialised in a different direction.
<br><br>- A class is a module which needs to export at least two functions<br><br>    superclass() -> SuperClassName.<br>    method(Message) -> {result,MethodResult} | no_method.<br><br>  Inheritance is handles by the superclass/0 function.
<br><br>- There is a dispatch function:<br><br>    dispatch(Method, Class) -><br>        case Class:method(Method) of<br>            {result,Result} -> {result,Result};<br>            no_method -><br>                Superclass = Class:superclass(),
<br>                dispatch(Method, SuperClass)<br>        end.<br><br>- For a system with multiple inheritance superclass/0 returns a list of classes.<br><br>- You would need some top superclass to properly handle the case of no method being found.
<br><br>It was all very basic and never expanded into full implementation. For concurrent objects you would wrap dispatch in a process otherwise call it directly. A lot of things are missing, for example you would need a state argument as in gen_server.
<br><br>The rest of the chapter was a discussion of why we thought that OO *design* might be acceptable but why OO *languages* are not.<br><br>Interestingly enough this is probably how dynamic OO languages handle it internally, here it was explicit. This would be slower but allow for complete control of the flavour of OO. Today you could wrap it very neatly in a fun for non-concurrent objects and wrap the fun in a process for concurrent ones. It is perfectly feasible to do this way.
<br><br>There have been a number of attempts at building a "proper" OO package for Erlang but none has really found acceptance and been seriously used.<br><br>One thing you must realise is that we were *not* more favourably disposed towards OO then than we are now so you must not take that chapter too seriously. We were right then and we are right now. COP forever. :-) 
<br></div><br>Robert (who wrote the chapter)<br><br></div>