[erlang-questions] mutable state

[OvermindDL1]

On May 11, 2014 4:21 AM, "Joseph Wayne Norton" <norton@REDACTED>
wrote:
>
>
> 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.
>
> There is such a mechanism for an implementation of Scheme on the Erlang
VM.
>
> http://the-concurrent-schemer.github.io/scm-doc/
>
http://the-concurrent-schemer.github.io/scm-doc/contributors.html#getting_started
>
> 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:
>
> https://github.com/the-concurrent-schemer/scm/blob/dev/src/scmi_env.erl
> https://github.com/the-concurrent-schemer/scm/blob/dev/c_src/scmi_env.cc
>
> 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!
>
>
> On 2014/05/11, at 16:29, semmit mondo <semmitmondo@REDACTED> wrote:
>
> > Hi,
> >
> > I'm working on a project that tries to bring a mutable state, OO
language to the
> > BEAM.  I believe this isn't impossible, but would like to ask your
opinion on how
> > to map certain OO constructs to Erlang, and how to bypass immutable
state
> > constraints.  (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 to
> > an object, and when I change the object using one of my references, the
view of
> > the object should change with the other ref.  I would like to represent
these things
> > in Erlang/BEAM as low level as possible.  One of my first ideas is that
let's use
> > Erlang variables (or BEAM registres) to hold a reference to a tuple
that represents
> > an object.
> >
> >   Ref1 = {object, Class, InstanceVariables}.
> >   Ref2 = Ref1.
> >
> > Instancevariables is a dict (gb_tree, of whatever), but the problem is
that I just
> > can'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 there
> > a way to get out of this trap?  I guess the tuple resides on the heap
and it consists
> > of 3 pointers to it's three members.  It I could update the third
pointer in that
> > tuple, that could solve my problem.  Is there somethong like
setelement/3, that
> > updates an existing tuple in place?  I know that this is exactly what
Erlang wants
> > to avoid, bu again, in order to port other languages to BEAM, at some
point I have
> > to bypass immutable state somehow.
> >
> > I know about process dictionaries.  That is really a great thing for
those who want to
> > do something like me.  The only problem is that it's only a single
dictionary, but I
> > need 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 have
> > references to the same object on different places in the code, while I
can use the
> > process dictionary to hold all my objects by refs as keys.  This allows
me everything I
> > want.  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 and
> > prevent automatic garbage collection to work for me.  My other concern
is that there
> > can be a very large number of objects and maybe process dictionaries
aren't
> > designed 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 table
> > per process is something considered a bad practise.  So I guess they
are not the
> > right solution for my problem.
> >
> > Any idea how can I have an in-place updatable dicts on the heap?  Or
how to do
> > OO object representation better?  Are there other things similar to the
process
> > dictionaries that can hold mutable state?
> >
> > THX
> >
> >

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.

 _______________________________________________
> > erlang-questions mailing list
> > erlang-questions@REDACTED
> > http://erlang.org/mailman/listinfo/erlang-questions
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140511/74b40505/attachment.htm>