Getting module of a class

[Don Clugston]

Bill Baxter wrote:
> On Fri, Oct 17, 2008 at 10:18 PM, Don <nospam at nospam.com.au> wrote:
>> Bill Baxter wrote:
>>> I find myself sometimes wanting to get an alias to the module
>>> namespace that a given type came from.
>>>
>>> The reason is this:  these days it's en vogue to make classes contain
>>> as few functions as necessary, and to write everything else as
>>> non-member functions.  The problem is that when you are using
>>> BigCoreDataStructure a lot in your program it's natural to import that
>>> from other modules and in the end you can lose sight of which module
>>> BigCoreDataStructure came from (it could be aliased to something else
>>> like "BCDS" in your current namespace for instance.)
>>>
>>> But now you have a problem because you have access to BCDS but you
>>> also want to get at his auxillary non-member functions.    But those
>>> didn't get imported because they would gum up the namespace.
>>>
>>> I'm thinking it would be nice if you could do something like
>>> ModuleOf(BCDS).ANonMemberFuncton to get at one of those non-member
>>> functions in BCDS's module whatever that may be.
>>>
>>> I think types do have the information of which module they originated
>>> in, so technically it should be possible.  Has anyone written a
>>> routine that can do this?
>>>
>>> --bb
>> Yes. It's in my meta.NameOf module. Which hasn't been updated in quite some
>> time...
>>
> 
> Neat.  Does always give you the true module of definition?
> Or does it return the module from which the symbol was most
> immediately imported?
> 
> For instance if we have this situation:
> 
> -----OriginalModule.d-----
> struct TheThing { ... }
> 
> ----OtherModule.d-----
> import OriginalModule: SneakyAlias = TheThing;
> 
> ----FinalModule.d-----
> import OtherModule : SneakyAlias;
> 
> moduleOf(SneakyAlias);  // does this resolve to OriginalModule or OtherModule?
> ------------------------------

It gives you OriginalModule. Aliases get resolved.