[erlang-questions] object vs. actor (Re: Massive Numbers of Actors vs. Massive Numbers of Objects vs. ????)

[Michael Turner]

> .... The serialised version
> of the data produced by term_to_binary/1 won't reliably unserialise if
> you change Erlang release or update any of your program's code that the
> fun used.

Does term_to_binary/1 on a fun produce BEAM code? I don't think so,
and that's the only reason (besides using deprecated functions in the
fun) that I can think of, for why it would break after an Erlang
release or two. And let's say you updated other code in your
application. If the fun accesses the changed module, it'll call the
new code -- the only reason it would break, I think, is if you
violated some basic encapsulation discipline in the module, or the
module's interface changed significantly.

The idea of persisting Erlang funs in this way makes me queasy. Then
again, anything like non-plain-text code embedded in data make my skin
crawl. (I think there's something in the Old Testament about how it's
a sin in the sight of God.) The conditions for making it work reliably
in Erlang don't seem to be difficult to meet, however.

-michael turner

On Sun, Mar 11, 2012 at 10:58 AM, Jeff Schultz <jws@REDACTED> wrote:
> On Sun, Mar 11, 2012 at 12:03:06PM +1100, Jeff Schultz wrote:
>> Note that the fun returned from loop/1 on receipt of the suspend
>> message captures the current State.
>
> Of course, tricks like this are very brittle.  The serialised version
> of the data produced by term_to_binary/1 won't reliably unserialise if
> you change Erlang release or update any of your program's code that the
> fun used.
>
>
>    Jeff Schultz
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions