[erlang-questions] mutable state

[zxq9]

On Monday 12 May 2014 16:59:24 ok@REDACTED wrote:
> On second thought, the obvious and natural way to model
> objects in Erlang is as processes.
> 
> An object executes
> 
> loop(Var1, Var2, ..., Varn) ->
>     receive
>         {selector,Arg...} ->
>             do some stuff,
>             loop(Var1', Var2', ..., Varn')
>       ; ...
>     end.
> 
> This is pretty much what Hewitt's actors did, and pretty much
> what an early version of Smalltalk did.
> 
> You get objects with identity and state; you get synchronous
> and asynchronous message sends; you get *distributed* objects.
> The one thing you do not get is classes, although delegation is
> easy to arrange.
> 
> However, inheritance is simply a way of *writing* OO programs;
> there doesn't have to be anything analogous to inheritance
> happening at run time.
> 
> (Come to think of it, you *could* have classes and inheritance.)

Considering that a C++/Java style class is a higher-order function that 
returns a struct of functions, basic types and pointers to other structs (with 
a bit of syntactic sugar to very lightly abstract this fact away and a 
truckload of marketing rhetoric to make it seem more special than it is), and 
that Alan Kay's definition of "Object-Oriented" was something he hoped would 
eventually include every object getting its own address (even URL and/or IP 
address!)... it is hard for me to feel that the typical crop of "OOP" 
languages aren't actually a special category of syntactially contorted 
functional languages, and that Erlang is in fact one of the extremely rare 
truly Object Oriented ones (by Kay's original definition, not, say, Gosling's).

Oddly, ever since I realized this I've become better at languages like Python 
and Java, don't mentally shutdown when I read C that implements C++-style OOP, 
and now can more quickly identify situations where Erlang is either The Right 
Thing or a mental minefield.

All that said, I really think the OP is barking up the wrong tree, trying to 
force something that already does what he wants to do it in the way he thinks 
it should rather than the way it was designed. It reminds me of attempts I 
periodically come across at things like implementing type-inference systems 
within Python frameworks or writing an entire imperative program within a 
single huge I/O monad in Haskell.