Longstanding issues: structs & standalone Erlang

[Thomas Lindgren]

--- Romain Lenglet <lenglet@REDACTED>
wrote:

> The equivalent solution in Erlang would be to always
> specify the 
> version of a module when using it, and to modify the
> runtime 
> accordingly, e.g.:
> {io, '2.1'}:format("hello~n", []).
> Problem are: 1) that looks ugly in Erlang, 2) module
> versions are 
> optional, 3) modules are not a unit of installation
> / 
> configuration (applications are such units, and it
> is their 
> versions that are important), 4) how to do dynamic
> code updates?

If Erlang had an explicit notion of linking, it might
work, e.g., by specifying somewhere that 'io' actually
refers to module io with -vsn("2.1"). and that the
code of io:format is the function found in the code
object named (io, "2.1"). Calls to apply/3 would have
to use a runtime association mapping atoms to actual
modules. Code change could perhaps be done by explicit
relinking, etc, (While Erlang's code change model is a
pretty good local optimum, it doesn't seem to
generalize very far beyond that point.) But I think
this needs a bit more thought.

Also, note that in practice, modules actually _are_ a
unit of installation. Some projects or companies don't
use applications or releases; other projects install
smaller patches by loading new modules.  (At this
time, I have actually worked in more Erlang companies
that _don't_ use fullblown OTP than such that do :-)

Best,
Thomas


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com