Packages in Erlang: new documentation

[Vlad Dumitrescu]

Hi,

From: "Richard A. O'Keefe"

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

Erm, no... We are comparing a remote function call with a remote function call
_plus_ a lookup - the latter can never be faster than the former, right?

>> 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.
> So instead of sending {foo,bar} to another module you'd send
> {?MODULE(foo),bar}.

Yes, could work. Chris' suggestion of using a macro for each renamed module is
even better, as it completely removes the lookup.

> Is there _any_ way of allowing abbreviations that is _not_ going to be
> error-prone?

No, not really. But the benefits might overweigh the disadvantages, so the
overall effect might be positive.

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

No, a static reference to the module is not good enough. Imagine a module
defining a fun and at a later moment the module's code is being upgraded - and
the name mapping changes! That would probably make the original fun crash in an
obscure way.

I agree, this is no good programming practice, but if something can happen, it
wil lhappen sooner or later.

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

Hmm, good point. Maybe Richard Carlsson can comment on this. Is the module
abbreviation going to work with variables as module names, or only at
compile-time?

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

I meant that if I write an application named foofoo, and later have to rename it
to barbar, then today I have to rename all foofoo_something modules and the
references to them, both from inside tha application and from its clients. With
the proposed scheme, only references from the outside need to be changed. It's
not really a big problem, I agree.

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

Maybe, maybe not. This is what we try to find out :-) I just wanted to point out
that no solution is perfect, and thus we have to try to find one that fits best
with what we need most.

best regards,
Vlad