[erlang-questions] mutable state

[semmit mondo]

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