<div dir="ltr"><div><div><div><div>It loses the GC in the sense (also explained in the OP) that the GC cannot detect when an object reference is no longer in use and then respond to that by cleaning up the process dictionary.<br>
<br></div>Indeed, while emulating objects with mutable state can be done in a number of ways in Erlang (using process dict / ETS / processes / resource binaries), getting GC into the picture appears to be the trickier part.<br>
</div>There is only (afaik) one reference-tracing mechanism in Erlang - the heap GC - and that one works only with immutable state.<br><br></div>(Elaborating on what OK said about wrecking the garbage
collector by going behind the VM's back and modifying existing tuples etc.: The Erlang GC is a generational GC which takes advantage of the fact that old objects can never refer to younger ones. That invariant makes generational GC easyish to implement, but breaking that invariant would make the VM crashyish.)<br>
<br></div>In short - the question is interesting, but Erlang does not supply GC-for-mutable-objects, so in any case you'd have to bring that - whether a reference-counting or tracing GC.<br><div><br></div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">2014-05-12 0:16 GMT+02:00 <span dir="ltr"><<a href="mailto:ok@cs.otago.ac.nz" target="_blank">ok@cs.otago.ac.nz</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">> Hi, I'm working on a project that tries to bring a mutable state, OO<br>
</div>> language to the BEAM. I believe this isn't impossible, but would like<br>
<div class="">> to ask your opinion on how to map certain OO constructs to Erlang, and how<br>
> to bypass immutable state constraints.<br>
<br>
</div>If it were possible for you to do so, you would wreck the garbage<br>
collector, which would be a Very Bad Thing.<br>
<br>
Two obvious things to try are<br>
- the (per-)process dictionary<br>
- ETS tables.<br>
As for the (per-)process dictionary, each Erlang process<br>
has what is in effect a hash table mapping immutable values<br>
to immutable values. So you could map<br>
{Object_Reference, Slot_Name} keys<br>
to arbitrary *immutable* values.<br>
ETS tables let you do the same thing on a larger scale and<br>
visible to multiple processes.<br>
<div class="">> The only problem is<br>
> that it's only a single dictionary, but I need at least one mutable<br>
> hash/dict per object in order to hold mutable state.<br>
<br>
</div>No, you don't. You need a replaceable slot per *field*.<br>
And {Object_Reference, Field_Name} pairs give you exactly that.<br>
<br>
And of course using the per-process dictionary does NOT lose you<br>
the Erlang GC. Why would it?<br>
<div class="HOEnZb"><div class="h5"><br>
<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>
</div></div></blockquote></div><br></div>