Packages in Erlang: new documentation

[Vlad Dumitrescu]

From: "Richard A. O'Keefe"
>> Yes, but it does not work in Erlang, because there your _cannot_
>> rename a module, since you cannot know if someone is going to
>> call it via apply(M, F, [...]) or spawn(M, F, [...]). It is not
>> possible to know in general what the M:s are, or even to which
>> M the caller is actually referring (the first M, or the later added
>> one that was renamed?)
>
> Clearly I must have misunderstood *someone*, because to make what I
> thought was proposed work, all you have to do is have a local table
> of renamings in the module, and then have apply/3 and spawn/3 and so
> on look in that table.

Hi,

While I think it would be a nice solution, I don't think it works that easily.
Please anyone correct me if I am wrong.

For the first, that would mean that every remote call will have to check first
the internal module table for a rename. That would make these calls much slower.

Then there must be a check for non-overlapping renames, because that would open
for some hard to find bugs. That would be at compile-time, so probably not a
problem.

Again, if a module name is sent as a function argument, the local name wouldn't
make sense to any other module. Sure, we could have a function to retrieve the
complete name, but personally I feel it's more error-prone than elegant.

Finally, what about functional objects? The environment for a closure would need
to include the rename table from the defining module.

These problems are solvable, but look like are imposing more restrictions for
the programmer than they remove.

>In short, from the inside, there appears to be no significant difference
>between a module name like foo_bar_baz and a module name like foo.bar.baz.

Only that locally you can use baz:fun(...) instead of the full module name. And
also that maybe one wants/needs to rename the 'foo' application, and then not
all module names have to be updated.

best regards,
Vlad