[erlang-questions] OO programming style in Erlang?

[Sean Hinde]

On 23 Jan 2007, at 17:30, Ladislav Lenart wrote:

> Sean Hinde wrote:
>> A certian Lisp/Smalltalk hacker round these parts keeps telling me  
>> that
>> Smalltalk is something like Erlang in concept, but I never quite
>> listened hard enough to see why ;-)
>
> But from a point of view of an experienced Smalltalker,
> I must say that the shift from Smalltalk to Erlang is not
> so trivial, mainly because of a quite complex and fixed
> syntax. I got quite used to the idea of minimal language
> syntax and extendable libraries over the years. And this
> I miss a lot in Erlang. A simple example to illustrate my
> point follows (maybe you will even tell me a simple way
> how to do something like this in Erlang?)...

And now you are at it as well !

>
> Let's suppose I have to write a lot of code like this
> in Smalltalk:
>
>    anObject isNil
>      ifFalse: [anObject doSomething].

Well, fairly meaningless so far.

One comment - Erlang is not about sending messages as some kind of  
alternative to calling a method. Code that implements the business  
logic is normally written as a bunch of pure functions that take data  
structures as inputs and return manipulated data structures. No side  
effects or external state change in sight. String a bunch of these  
together and you have as complex a logic as you want.

Data structures are by nature highly symbolic (the atom type) and  
(apart from dedicated ADTs like dict and gb_trees) tend to be  
complex, exposed and passed around and operated on directly by pure  
functions.

The process structure in a typical Erlang based system is not about  
distributing state, but more about modelling things that have to  
happen concurrently.

>
> I can "extend the language" by providing a new method
> which takes a block of code as its only argument:
>
>    Object>>ifNotNilDo: oneArgBlock
>      "This is the branch where object (self in this
>       context) is not nil and so the block is evaluated
>       (with the object as its argument)."
>      ^oneArgBlock value: self.
>
>    UndefinedObject>>ifNotNilDo: oneArgBlock
>     "This is the branch where object (self in this
>      context) is actually nil and so the block is ignored
>      and nil is returned."
>      ^self.
>
> Now I can replace the code above with shorter and more
> readable form:
>
>    anObject ifNotNilDo: [:obj | obj doSomething].

In Erlang you just write what you mean.

function(false) -> do_something_with_false();
function(Not_false) -> do_something_else(Not_false).

There is no complicated way to add a new clause to this function,  
only the simple and obvious:

function(false) -> do_something_with_false();
function({error, Reason}) -> do_something_with_error(Reason);
function(Not_false) -> do_something_else(Not_false).

No need for all the multi levels of indirection and "no idea what  
might be overriding this" but grep might help problems ;-)

As far as I can see the only time you might ever need to add some  
clauses to such a function via some other source code file is if you  
were using a closed source library. Then you would just put a wrapper  
function around the library:

wrapper({my_data, Data}) -> do_my_stuff(Data);
wrapper(Else) -> closed_lib:function(Else)

But hey, there are no closed source libraries for Erlang.

Perhaps the closest thing to what you are after is the an OTP  
behaviour. But almost every complex Erlang System uses no more that  
the 2 or 3 that come with OTP (gen_server, errr, actually that would  
suffice!)

>
> Sorry for the Smalltalk excursion... :-)

Quite alright. I did download Squeak the other day, but couldn't  
figure out how to start an emacs buffer

Sean