Abstract Modules (was Re: erl_eval.erl : Mucho weirdness)
Wed May 25 16:27:35 CEST 2005
On 25 May 2005, at 13:04, Vlad Dumitrescu wrote:
> From: "Sean Hinde" <sean.hinde@REDACTED>
>>> Or do you mean that there should be a way to use the name (atom)
>>> as a
>>> regular module name in function calls, and the name-to-module
>>> translation should be done behind the scenes?
>> Yes, this is what I meant, only much less elegantly put :)
> Oh, I see :-)
> I can see a problem with this: the client module makes calls to
> what looks
> like a regular module, but in fact is something else. Maybe the
> problem will be finding the source code for that module, but I feel
> it's not
It is not very pure certainly. It would still be useful however if it
was restricted to a single named instance with the same name as the
module name in the source code. There would be no difficulty with
finding the source code, and it would be normally be initialised
sometime during system startup.
> Not to mention the possibility of getting name clashes: if a
> regular module
> with same name exists, which one should be called?
Indeed. Restricting to one instance with the name of the module would
solve this with some loss of flexibility.
> <wild idea>
> A clean way to handle this would be to make the client modules
> abstract too,
> with the original abstract module as a parameter.
> This would recursively force all modules that make external calls
> to become
> abstract, and then why not make modules a data type and skip the
Yes, this would also probably do, but could end up an even worse
maintenance nightmare - not to mention the increased probability of
introducing circular dependencies.
So, In conclusion I would restrict such a thing to a single instance
named after the abstract module. A new kind of new() call could be
added to initilaise this variant, maybe:
More information about the erlang-questions