export_to (Was: Re: the OO metaphor)

[Bjorn Gustavsson]

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).

/Björn

Thomas Lindgren <thomasl@REDACTED> 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
> they?
> 
> 		       Thomas
> --
> Thomas Lindgren					thomas+junk@REDACTED
> 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
bjorn@REDACTED      ÄT2/UAB/F/P
			    BOX 1505
+46 8 727 56 87 	    125 25 Älvsjö