<p dir="ltr"><br>
On May 11, 2014 4:21 AM, "Joseph Wayne Norton" <<a href="mailto:norton@lovely.email.ne.jp">norton@lovely.email.ne.jp</a>> wrote:<br>
><br>
><br>
> You can try using a NIF object that acts as an environment for your objects. The NIF object and it's associated terms will be garbage collected when the NIF object is no longer referenced by the Erlang VM.<br>
><br>
> There is such a mechanism for an implementation of Scheme on the Erlang VM.<br>
><br>
> <a href="http://the-concurrent-schemer.github.io/scm-doc/">http://the-concurrent-schemer.github.io/scm-doc/</a><br>
> <a href="http://the-concurrent-schemer.github.io/scm-doc/contributors.html#getting_started">http://the-concurrent-schemer.github.io/scm-doc/contributors.html#getting_started</a><br>
><br>
> Try the above getting started link to see an example that uses such a NIF object. The code for the environment resource can be found here:<br>
><br>
> <a href="https://github.com/the-concurrent-schemer/scm/blob/dev/src/scmi_env.erl">https://github.com/the-concurrent-schemer/scm/blob/dev/src/scmi_env.erl</a><br>
> <a href="https://github.com/the-concurrent-schemer/scm/blob/dev/c_src/scmi_env.cc">https://github.com/the-concurrent-schemer/scm/blob/dev/c_src/scmi_env.cc</a><br>
><br>
> There is an underlying issue if these NIF objects are long lived with many mutable states ... there is currently no GC for the old values held in the NIF's environment. Mileage will vary!<br>
><br>
><br>
> On 2014/05/11, at 16:29, semmit mondo <<a href="mailto:semmitmondo@freemail.hu">semmitmondo@freemail.hu</a>> wrote:<br>
><br>
> > Hi,<br>
> ><br>
> > I'm working on a project that tries to bring a mutable state, OO language to the<br>
> > BEAM. I believe this isn't impossible, but would like to ask your opinion on how<br>
> > to map certain OO constructs to Erlang, and how to bypass immutable state<br>
> > constraints. (Yes, I know that this sounds stupid, but that's what I need.)<br>
> ><br>
> > The fundamentals of that I want to do is to be able to have two references to<br>
> > an object, and when I change the object using one of my references, the view of<br>
> > the object should change with the other ref. I would like to represent these things<br>
> > in Erlang/BEAM as low level as possible. One of my first ideas is that let's use<br>
> > Erlang variables (or BEAM registres) to hold a reference to a tuple that represents<br>
> > an object.<br>
> ><br>
> > Ref1 = {object, Class, InstanceVariables}.<br>
> > Ref2 = Ref1.<br>
> ><br>
> > Instancevariables is a dict (gb_tree, of whatever), but the problem is that I just<br>
> > can't update the dict without creating a completely new dict and a new tuple.<br>
> > So, whatever I do with Ref1, I won't see anything changing with Ref2. Is there<br>
> > a way to get out of this trap? I guess the tuple resides on the heap and it consists<br>
> > of 3 pointers to it's three members. It I could update the third pointer in that<br>
> > tuple, that could solve my problem. Is there somethong like setelement/3, that<br>
> > updates an existing tuple in place? I know that this is exactly what Erlang wants<br>
> > to avoid, bu again, in order to port other languages to BEAM, at some point I have<br>
> > to bypass immutable state somehow.<br>
> ><br>
> > I know about process dictionaries. That is really a great thing for those who want to<br>
> > do something like me. The only problem is that it's only a single dictionary, but I<br>
> > need at least one mutable hash/dict per object in order to hold mutable state.<br>
> ><br>
> > Another ide of mine is to represent object references with unique IDs (just numbers,<br>
> > or Refs) in a tuple like {ref, 2763456} or {ref, make_ref()}. This allows me to have<br>
> > references to the same object on different places in the code, while I can use the<br>
> > process dictionary to hold all my objects by refs as keys. This allows me everything I<br>
> > want. The only problem is that this way I lose the ability to use the built-in GC of BEAM.<br>
> > Even if I drop all the references to an object, the process dictionary will hold them and<br>
> > prevent automatic garbage collection to work for me. My other concern is that there<br>
> > can be a very large number of objects and maybe process dictionaries aren't<br>
> > designed for this, and therefore they aren't efficient enough for the job. However,<br>
> > I don't know about any other way to achieve what I want.<br>
> ><br>
> > ETS tables looked promising for the first sight, but even having one single ETS table<br>
> > per process is something considered a bad practise. So I guess they are not the<br>
> > right solution for my problem.<br>
> ><br>
> > Any idea how can I have an in-place updatable dicts on the heap? Or how to do<br>
> > OO object representation better? Are there other things similar to the process<br>
> > dictionaries that can hold mutable state?<br>
> ><br>
> > THX<br>
> ><br>
> ></p>
<p dir="ltr">Why not just represent the objects as an actor per instance, that is what the actor pattern is for, send messages to mutate or query state.<br><br></p>
<p dir="ltr"> _______________________________________________<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">http://erlang.org/mailman/listinfo/erlang-questions</a><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">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</p>