<div>Hi,</div>
<div> </div>
<div>I'm working on a project that tries to bring a mutable state, OO language to the</div>
<div>BEAM. I believe this isn't impossible, but would like to ask your opinion on how</div>
<div>to map certain OO constructs to Erlang, and how to bypass immutable state</div>
<div>constraints. (Yes, I know that this sounds stupid, but that's what I need.)</div>
<div> </div>
<div>The fundamentals of that I want to do is to be able to have two references to</div>
<div>an object, and when I change the object using one of my references, the view of</div>
<div>the object should change with the other ref. I would like to represent these things</div>
<div>in Erlang/BEAM as low level as possible. One of my first ideas is that let's use</div>
<div>Erlang variables (or BEAM registres) to hold a reference to a tuple that represents</div>
<div>an object.</div>
<div> </div>
<div> Ref1 = {object, Class, InstanceVariables}.</div>
<div> Ref2 = Ref1.</div>
<div> </div>
<div>Instancevariables is a dict (gb_tree, of whatever), but the problem is that I just</div>
<div>can't update the dict without creating a completely new dict and a new tuple.</div>
<div>So, whatever I do with Ref1, I won't see anything changing with Ref2. Is there</div>
<div>a way to get out of this trap? I guess the tuple resides on the heap and it consists</div>
<div>of 3 pointers to it's three members. It I could update the third pointer in that</div>
<div>tuple, that could solve my problem. Is there somethong like setelement/3, that</div>
<div>updates an existing tuple in place? I know that this is exactly what Erlang wants</div>
<div>to avoid, bu again, in order to port other languages to BEAM, at some point I have</div>
<div>to bypass immutable state somehow.</div>
<div> </div>
<div>I know about process dictionaries. That is really a great thing for those who want to</div>
<div>do something like me. The only problem is that it's only a single dictionary, but I</div>
<div>need at least one mutable hash/dict per object in order to hold mutable state.</div>
<div> </div>
<div>Another ide of mine is to represent object references with unique IDs (just numbers,</div>
<div>or Refs) in a tuple like {ref, 2763456} or {ref, make_ref()}. This allows me to have</div>
<div>references to the same object on different places in the code, while I can use the</div>
<div>process dictionary to hold all my objects by refs as keys. This allows me everything I</div>
<div>want. The only problem is that this way I lose the ability to use the built-in GC of BEAM.</div>
<div>Even if I drop all the references to an object, the process dictionary will hold them and</div>
<div>prevent automatic garbage collection to work for me. My other concern is that there</div>
<div>can be a very large number of objects and maybe process dictionaries aren't</div>
<div>designed for this, and therefore they aren't efficient enough for the job. However,</div>
<div>I don't know about any other way to achieve what I want.</div>
<div> </div>
<div>ETS tables looked promising for the first sight, but even having one single ETS table</div>
<div>per process is something considered a bad practise. So I guess they are not the</div>
<div>right solution for my problem.</div>
<div> </div>
<div>Any idea how can I have an in-place updatable dicts on the heap? Or how to do</div>
<div>OO object representation better? Are there other things similar to the process</div>
<div>dictionaries that can hold mutable state?</div>
<div> </div>
<div>THX</div>
<div> </div>