public import and bugs it causes

Simen kjaeraas simen.kjaras at gmail.com
Fri May 14 14:01:22 PDT 2010


Alex Makhotin <alex at bitprox.com> wrote:

> I don't want to deal with the bad design of someone's module.
> For example.

You're gonna have to deal with that in all other ways. Why is this
functionality so important to get rid of?

>> module Server.TestM2;
>> const string name = "New Name";
>
>> module Server.TestM1;
>> public import Server.TestM2;
>
>> module Server.Main;
>> private import Server.TestM1;
>
> In the scope of Server.Main module the global variable 'name' is visible.
> That should not be so.

Yes it should. The designer of TestM1 decided so. Just like he decided so
for all classes, structs, enums, and whatnots in TestM1. Perhaps you only
want TestM1.foo? Then import it properly, so you don't need to worry about
it (That would be import TestM1 : foo. Or, if you want your bondage:
static import).

> The use of globals is error prone. I consider it a bad practice.
> In the extreme case I would like to see D's specification restricting  
> globals as C# does.

Gods, no.

-- 
Simen


More information about the Digitalmars-d mailing list