Abstract Modules (was Re: erl_eval.erl : Mucho weirdness)

[Sean Hinde]

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  
> biggest
> problem will be finding the source code for that module, but I feel  
> it's not
> proper...

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
> "abstractness"?
> ;-)
> </>

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:

mod:named_new([Param1, Param2]).

Sean