Don Clugston wrote:
> David Medlock wrote:
> 
>> Jari-Matti Mäkelä wrote:
>>
>>> Sean Kelly wrote:
>>>
>>>> Chris Miller wrote:
>>>>
>>>>> On Sun, 15 Jan 2006 05:17:56 -0500, Walter Bright
>>>>> <newshound@digitalmars.com> wrote:
>>>>>
>>>>>
>>>>>> "David Medlock" <noone@nowhere.com> wrote in message
>>>>>> news:dq1l4p$8dq$1@digitaldaemon.com...
>>>>>>
>>>>>>> Do you consider this a bug Walter?
>>>>>>
>>>>>>
>>>>>>
>>>>>> No. Just as in C++, access checks are done *after* name lookup and
>>>>>> overload
>>>>>> resolution.
>>>>>
>>>>>
>>>>>
>>>>> This sucks. Sorry, but why should something completely unusable and
>>>>> undocumented cause conflicts. I do run into this problem quite often,
>>>>> and I believe I've made a NG post about it before.
>>>>
>>>>
>>>>
>>>> Agreed.  And this simply isn't an issue in C++, as implementation
>>>> details can be hidden in source files.  Though I guess they can in D as
>>>> well now that we have the -H compiler option.
>>>
>>>
>>>
>>>
>>> IMHO -H option is not a proper solution here - private really means
>>> private and should be "hidden" from the other modules even when we have
>>> access to the full source code. This really sucks and is the most
>>> annoying thing in D to me.
> 
> 
> Indeed. Especially since it's an identifier conflict rather than a true ambiguity.
> 
>>>
>>> Walter, please think of a project with tens of thousands of classes. How
>>> should one know, whether a method name is already "reserved" in another
>>> module or not?
>>>
>>
>> I agree.  The namespace should not be polluted with private members.
>>
>> The whole point of private is
>> 1. To prevent namespace conflicts
>> 2. To isolate the replaceable(implementation) aspects of your module
> 
> 
> I agree.
> 
>> #2 is fullfilled here, but not #1.
> 
> 
> I disagree that even #2 is fulfilled. If you change the name of a private member, you risk breaking code elsewhere.
> 
> --> you can change the behaviour of private members, you can delete them , but you cannot add new ones safely.
> 
> This is not much of a problem for class members, but for free functions and templates, it's a real issue.
> 
> Try putting a private function in std.stdio called
> void func() {}
> and see how many test programs break.
> 
>   If I cannot call or extend the
> 
>> private parts(hehe) then why should I see them?
> 
> 

My vote goes too to the side that thinks this behaviour is not ideal, and should be improved/fixed.

>> Walter, pragmatically this rule makes no sense for C++ or D.
>> ( At least across modules it doesnt)
> 
> 
> This has never once been a problem for me in C++, but I'm encountering it all the time in D.
It should be because of C++'s namespacing structure, no?
C++'s namepacing structure allows for a programming style where most non-local entities are acessed by partially qualified names and not unqualified names. In D the same is (possible, altough) not so easy or flexible to do. Unlike other languages, D is geared torwads the use of unqualified names, and then such problems arise.

In Java the problem is different: Since classes take the role of modules and latter name qualifiers, all possible conflicts arise at import time. In C# it works (or breaks :P) just as D.

Changing D's naming methodology might deal with this problem, but I think that it might not be the best way. I'm not totally experienced on this, but I guess I agree with the disambiguation ideas proposed here.

Note: Nonetheless, I do *inexorably* think that D's naming structure & methodology should, if not *must*, be changed. It is however, for different reasons.
-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to be... unnatural."