Irritating shortcoming with modules and externs

[Chris Nicholson-Sauls]

Bruno Medeiros wrote:
> Jarrett Billingsley wrote:
> 
>> "Mike Parker" <aldacron71 at yahoo.com> wrote in message 
>> news:e4ed7h$162h$2 at digitaldaemon.com...
>>
>>> Mike Parker wrote:
>>>
>>>> How about this:
>>>>
>>>> ##########################################
>>>> // main.d
>>>> module main;
>>>>
>>>> abstract class Context
>>>> {
>>>> public:
>>>>     abstract void run(char[][] args);
>>>>     protected:
>>>>     this()
>>>>     {
>>>>         theContext = this;
>>>>     }
>>>> }
>>>>
>>> Of course, there should be a null check in the constructor so that 
>>> only one primary cotext is ever set:
>>> if(theConext is null)
>>> theContext = this;
>>
>>
>> Oh that's really cool :)  I might go with that.
>>
> 
> I do something very similar:
> 
>   int main(char[][] args)
>   {
>     // .. proccess args..
>     // ..maybe load some libs (like Derelict)..
>     App.appmain();
>     return 0;
>   }
> 
> However, in my case, App is a module. If you only have one Context, and 
> it is allways active during the program lifetime, why bother creating a 
> singleton instead of simply using a module?
> 

The singleton pattern can be useful if you want to pass a reference to the singleton to 
some function or method later that expects an arbitrary object (maybe implementing a 
certain interface, for example).  Although, if you only have the one singleton, and 
there's no possible reason to pass it around, your point is dead-on.

-- Chris Nicholson-Sauls