<p dir="ltr">I agree. The question, as so often before, is: what do you *really* want to achieve?<br>
As they say, you can write COBOL in any language. And perhaps it is possible to implement a tracing garbage collector on top of Erlang so as to get objects with mutable state. But it would be wise to address the deeper "why?" in earnest before you do so.</p>

<div class="gmail_quote">Den 13/05/2014 05.50 skrev "zxq9" <<a href="mailto:zxq9@zxq9.com">zxq9@zxq9.com</a>>:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Monday 12 May 2014 16:59:24 <a href="mailto:ok@cs.otago.ac.nz">ok@cs.otago.ac.nz</a> wrote:<br>
> On second thought, the obvious and natural way to model<br>
> objects in Erlang is as processes.<br>
><br>
> An object executes<br>
><br>
> loop(Var1, Var2, ..., Varn) -><br>
>     receive<br>
>         {selector,Arg...} -><br>
>             do some stuff,<br>
>             loop(Var1', Var2', ..., Varn')<br>
>       ; ...<br>
>     end.<br>
><br>
> This is pretty much what Hewitt's actors did, and pretty much<br>
> what an early version of Smalltalk did.<br>
><br>
> You get objects with identity and state; you get synchronous<br>
> and asynchronous message sends; you get *distributed* objects.<br>
> The one thing you do not get is classes, although delegation is<br>
> easy to arrange.<br>
><br>
> However, inheritance is simply a way of *writing* OO programs;<br>
> there doesn't have to be anything analogous to inheritance<br>
> happening at run time.<br>
><br>
> (Come to think of it, you *could* have classes and inheritance.)<br>
<br>
Considering that a C++/Java style class is a higher-order function that<br>
returns a struct of functions, basic types and pointers to other structs (with<br>
a bit of syntactic sugar to very lightly abstract this fact away and a<br>
truckload of marketing rhetoric to make it seem more special than it is), and<br>
that Alan Kay's definition of "Object-Oriented" was something he hoped would<br>
eventually include every object getting its own address (even URL and/or IP<br>
address!)... it is hard for me to feel that the typical crop of "OOP"<br>
languages aren't actually a special category of syntactially contorted<br>
functional languages, and that Erlang is in fact one of the extremely rare<br>
truly Object Oriented ones (by Kay's original definition, not, say, Gosling's).<br>
<br>
Oddly, ever since I realized this I've become better at languages like Python<br>
and Java, don't mentally shutdown when I read C that implements C++-style OOP,<br>
and now can more quickly identify situations where Erlang is either The Right<br>
Thing or a mental minefield.<br>
<br>
All that said, I really think the OP is barking up the wrong tree, trying to<br>
force something that already does what he wants to do it in the way he thinks<br>
it should rather than the way it was designed. It reminds me of attempts I<br>
periodically come across at things like implementing type-inference systems<br>
within Python frameworks or writing an entire imperative program within a<br>
single huge I/O monad in Haskell.<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div>