Getting module of a class

[KennyTM~]

Andrei Alexandrescu wrote:
> Sergey Gromov wrote:
>> Sat, 18 Oct 2008 05:58:50 +0900,
>> Bill Baxter wrote:
>>> The truly simplest solution here is just to ignore Scott Meyer's
>>> advice and make nonMemberFunction a static member function.  That way
>>> if I have access to SomeClass I will always have easy access to
>>> nonMemberFunction, regardless of whatever round-about chain of imports
>>> and aliases got me SomeClass.
>>
>> To define a non-member, *non-friend* function in D you must define it 
>> in a different module than the module in which your class is defined.  
>> Good-
>> bye encapsulation.  :)
> 
> I agree. I'd also agree that file-level encapsulation does make sense. 
> After all, unless fancy code databases are used, the file is the 
> physical unit of protection and change tracking, and it's here to stay. 
> So I don't find one scheme inferior to the other.
> 
> A possible improvement would be to introduce "module" as a protection 
> level:
> 
> class A
> {
> public:
>    void fun(); // vale tudo
> module:
>    void gun(); // what private is now
> protected:
>    void hun(); // zis and derivees
> package:
>    void iun(); // package-level
> private:
>    void jun(); // really, really private. I mean it.
> }
> 
> I'm not sure how much this improve the state of affairs. I guess it's 
> one of those reddit-ish "Vote up if you want to attract Walter's 
> attention..."
> 
> 
> Andrei

... Off-topic a bit, but I'd rather to see “package” to be usable 
between sub-packages (e.g. somelib.feature1.all.d and 
somelib.feature2.all.d)