Packages in Erlang: new documentation
Richard A. O'Keefe
ok@REDACTED
Fri Sep 5 01:59:37 CEST 2003
"Vlad Dumitrescu" <vlad_dumitrescu@REDACTED> wrote:
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.
This is a bare assertion without any evidence to support it.
With appropriate use of hash tables and caches, it could be _faster_.
Again, if a module name is sent as a function argument, the
local name wouldn't make sense to any other module.
That is certainly a serious problem with the current proposal.
One solution would be to extend the ?MODULE idea.
?MODULE ==> the full name of the current module
+
?MODULE(local_name) ==> the full name of the module locally known as
local_name.
So instead of sending {foo,bar} to another module you'd send
{?MODULE(foo),bar}.
Sure, we could have a function to retrieve the complete name,
but personally I feel it's more error-prone than elegant.
Is there _any_ way of allowing abbreviations that is _not_ going to be
error-prone?
Finally, what about functional objects? The environment for a closure would need
to include the rename table from the defining module.
Not the _environment_. The parent module is simply part of the literal
data for the code.
>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 THAT is the thing that creates all these difficulties.
If baz:f(...) and (X = baz, X:f(...)) don't do the same thing,
the language has serious semantic problems.
If they _are_ to do the same thing, then either you don't have
abbreviations, or you _have_ to look up module names in a per-module
table somehow.
And also that maybe one wants/needs to rename the 'foo'
application, and then not all module names have to be updated.
Please explain this more clearly with an example.
The more I think about this, the clearer it seems that ANY kind of
dotted module name scheme is a bad idea, and that something like
the Eiffel approach is likely to be less trouble (more power, less
complexity, less potential for error).
More information about the erlang-questions
mailing list