[erlang-questions] Erlang Book 1996 vs. 2007

[Robert Virding]

On 19/09/2007, Dmitrii 'Mamut' Dimandt <dmitriid@REDACTED> wrote:
>
>  Toby DiPasquale wrote:
>
> This would be in conflict with Joe's statements about Erlang not being
> object-oriented, right
>
>  >From the TOC: http://erlang.org/erlang_book_toc.html
> 17   Object-Oriented Programming
>     17.1 Basic Concepts
>     17.2 Mapping to Erlang
>     17.3 An Object-Oriented Interface
>     17.4 Object-Oriented Programming
>     17.5 Object-Oriented Design
>
> I mostly interested in the "Mapping to Erlang" chapter as it could be
> quite useful when trying to port certain libraries to Erlang
>

Did you ever get a reply to this?

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.

- A class is a module which needs to export at least two functions

    superclass() -> SuperClassName.
    method(Message) -> {result,MethodResult} | no_method.

  Inheritance is handles by the superclass/0 function.

- There is a dispatch function:

    dispatch(Method, Class) ->
        case Class:method(Method) of
            {result,Result} -> {result,Result};
            no_method ->
                Superclass = Class:superclass(),
                dispatch(Method, SuperClass)
        end.

- For a system with multiple inheritance superclass/0 returns a list of
classes.

- You would need some top superclass to properly handle the case of no
method being found.

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.

The rest of the chapter was a discussion of why we thought that OO *design*
might be acceptable but why OO *languages* are not.

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.

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.

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. :-)

Robert (who wrote the chapter)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20071119/12662cd3/attachment.htm>