Georg Wrede wrote:
> Derek Parnell wrote:
>> This has been broken for a *long* time now. Both "private" and "package"  are just ignored by DMD for at least the last 5 or 6 releases. It used to  work but now it doesn't.
> 
> 
> How is anyone new to D supposed to even consider using it when stuff like _private_ and _package_ are broken????????????????????????
> 
> This is both *elementary* and *essential* to any nontrivial project. It simply *has* to work.
> 
> "Would you buy a 3-wheel Ferrari?"
> 
> The first guys we lose this way are those who were considering D for real work (as opposed to hobby or tinkering).

Dig dat, bro' ...

Apparently *so* fundamental that there's not even a stress-test for this kind of thing

Bruno Medeiros wrote:
> Sean Kelly wrote:
>> Dawid Ciężarkiewicz wrote:
>>> You write your great soft in D. You're coding with smile because everything
>>> in seems to be so good. You added few new files, new classes. Porting your
>>> project from C++ to D seems to be so good idea. You type "make".
>>>
>>> And then out of nowhere: BANG!!!
>>>
>>> battle.d(31): import battle.map conflicts with cell.cell.map at
>>> cell/cell.d(29)
>>
>> For what it's worth, the symbol resolution rules styled after the C++ class-scope rules.  On the surface, this does seem to provide solid support for the approach: it's a sticky issue and an established language has solved the problem this way, so why not do that?  However, I think the reasons that this rule was chosen for C++ may be related to language syntax that D simply doesn't have, thus reducing the strength of the correlation.
> 
> I can't figure out what kind of parallel or comparison could be made of symbol resolution with a language that has no structured module system. What would be the analogous case in C++ for the situation mentioned above? What are the C++ class-scope rules?

C++ class member symbol lookup is roughly similar to module-level lookup in D at a conceptual level, so Walter modeled the D lookup rules on this aspect of C++.  If you pretend a C++ class is a D module and use multiple inheritance instead of import you'll see identical behavior for symbol lookup.


Sean

kris wrote:
> Georg Wrede wrote:
>> Derek Parnell wrote:
>>> This has been broken for a *long* time now. Both "private" and "package"  are just ignored by DMD for at least the last 5 or 6 releases. It used to  work but now it doesn't.
>>
>>
>> How is anyone new to D supposed to even consider using it when stuff like _private_ and _package_ are broken????????????????????????
>>
>> This is both *elementary* and *essential* to any nontrivial project. It simply *has* to work.
>>
>> "Would you buy a 3-wheel Ferrari?"
>>
>> The first guys we lose this way are those who were considering D for real work (as opposed to hobby or tinkering).
> 
> Dig dat, bro' ...
> 
> Apparently *so* fundamental that there's not even a stress-test for this kind of thing
> 
> 

What do you mean? There are lot of testcases in DStress for protection attributes:
http://dstress.kuehne.cn/www/dstress.html#private_03


-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Chris Miller wrote:
> Here's a simple example of the issue:
> 
> 
> // -- foo.d --
> private import std.stdio;
> 
> 
> // -- bar.d --
> private import std.stdio;
> 
> 
> // -- test.d --
> 
> import foo, bar;
> 
> void main()
> {
>     char[] hi = std.string.toString(3);
> }
> 
> 
> DMD 0.160:
>    foo.d(1): import foo.std conflicts with bar.std at bar.d(1)
> 
> 
> Of course, the code in test.d is a mistake, but look how unhelpful the error message is. It will blame a library's code for a mistake the library-user made.
> 
> Also notice that it's considering *private* imports, which shouldn't even be available to test.d.

It's considering private imports because of bug 48, but this issue is not the same as bug 48, it is a separate bug, because it also happens with public imports.
Submitted as bug 209.


-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D