export_to (Was: Re: the OO metaphor)

[Martin Bjorklund]

Thomas Lindgren <thomasl@REDACTED> wrote:
> 
> > In order to manage code change without killing the process, fun's
> > should only be used for short tasks. By using a fun as the topmost
> > function in long lived server processes, you will effectively force
> > a kill of the process at next code change.
> 
> Good point, though the question it raises is whether the current code
> replacement semantics for fun:s is what we want. Wouldn't it be more
> useful if closures survived code change, for example? Why shouldn't
> they?

If they did, you would be forced to handle versions of funs yourself,
in the code.  Some funs in your state might be very old (and buggy!)
and some newer, even "the same" funs (just different incarnations).
You'd have to take care of that in the code.

I still think that funs are great for short-lived stuff, like looping
over a list, but whenever the "fun" is stored in a state, I think the
{Mod, Fun} (or {M,F,A}) syntax is the only way that works in practice,
due the code loading problem.

This is not a new problem, it has always been there (and that was one
of the reasons funs were not part of the language for a long time).


The only drawback with the current code loading mechanism is that
while it's very elegant in theroy, in combination with gen_server
et. al. it's ugly.  The problem here is that gen_server always calls
the call-back module with an external call, thus forcing a code
change.  Come to think of it, this could actually be solved by using a
fun instead of the call-back module!  Hey, klacke, we're back to
'generic' with the 'doit' function ;-)


/martin