export_to (Was: Re: the OO metaphor)
Mon Dec 4 11:12:58 CET 2000
Actually, in Beam R5 and later versions, funs do survive ONE code change.
That is, you can load a new version of a module and still call the old version
version of the code through an old fun. However, you can't change the code
a second time and still use the old fun. You would have to replace the fun
to a fun based on the new version of the code (which is not possible
to do if you spawned a fun directly).
Thomas Lindgren <> writes:
> > 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
> Thomas Lindgren
> Alteon WebSystems
> "National differences and antagonism between peoples are daily more and
> more vanishing, owing to the development of the bourgeoisie, to
> freedom of commerce, to the world market, to uniformity in the mode of
> production and in the conditions of life corresponding thereto."
> -- Communist Manifesto
Björn Gustavsson Ericsson Utvecklings AB
+46 8 727 56 87 125 25 Älvsjö
More information about the erlang-questions