Manfred Nowak wrote:

> David Medlock wrote:
// vis.d
import  std.stream, std.ctype, std.stdio;

void main( char[][] args )
{
  char c = ' ';
  if ( isdigit(c) ) writefln( "Hello World" );
}


which gives( DMD 0.141, WinXP ):

---------- Capture Output ----------
> "Z:\dmd\bin\dmd.exe" -c F:\proj\d\test\vis.d
Z:\dmd\bin\..\src\phobos\std\stream.d(2912): function std.stream.isdigit conflicts with std.ctype.isdigit at Z:\dmd\bin\..\src\phobos\std\ctype.d(32)
F:\proj\d\test\vis.d: module vis std.stream.isdigit is private

> Terminated with exit code 1.

the private members of stream should not even exist outside that module, if I read the specs correctly.

-DavidM >
>
> The specs installed by my installation of dmd 0.141 only define
> accessability: not one word on visibility.
>
> By the way: `private' symbols cannot be overriden?
>
> -manfred

You mean the ones you can't access you want to override?
You make no sense.

If you are serious, please explain how functions/classes you cannot access are overridden.

-David M

PS.
Reposted to bugs NG where I intended it.

Do you consider this a bug Walter?

"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.

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.

Possible solutions:
   1) Fix it in the compiler.
   2) Give your privates strange names; but you can't do that if it's an extern, e.g. accessing external C functions.
   3) Always use fully qualified names, but now we're back to the C way of always typing the most possible.
   4) Document the privates. e.g. Ddoc could output a "Warning" section saying "avoid these names:".
   5) See the compiler's output and fix conflicts as they happen, making you do extra work if you switch compilers / libraries / versions / etc.

In article <op.s3fs1jkypo9bzi@moe>, Chris Miller says...
>
>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.

There's an isdigit in std.stream? Why? This particular situation is bizarre!


>Possible solutions:
>    1) Fix it in the compiler.

We either need to convince Walter it's a bug, or he need to convince us what the compiler is doing makes sense. ;)

If isdigit doesn't show up in Ddoc, why does the compiler try to use it?

>    2) Give your privates strange names; but you can't do that if it's an
>extern, e.g. accessing external C functions.

I can already imagine someone defending "__is_____digit__" as an appropriate name. :(

>    3) Always use fully qualified names, but now we're back to the C way of
>always typing the most possible.

You probably already know this, but you can (at least partially) avoid fully qualified names with an alias for your favorite:

For example:
alias std.ctype.isdigit isdigit;

>    4) Document the privates. e.g. Ddoc could output a "Warning" section
>saying "avoid these names:".

Interesting idea, but I suspect the info would come later than needed if it's output from Ddoc.

>    5) See the compiler's output and fix conflicts as they happen, making
>you do extra work if you switch compilers / libraries / versions / etc.

If I understand what you mean right, this is probably the status quo for most people (i.e. what they've already been doing).

jcc7

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.


Sean

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.

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?

-- 
Jari-Matti

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.
> 
> 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

#2 is fullfilled here, but not #1.  If I cannot call or extend the private parts(hehe) then why should I see them?

Walter, pragmatically this rule makes no sense for C++ or D.
( At least across modules it doesnt)

-DavidM

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?

> 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.

Walter Bright 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 is a bug. Please fix.

It doesn't matter what C++ do, because for some reason this is not an issue there. It's been said dozens of times, D leads to new ways of programming, and then it is just silly to have a feature that leads to conflicts, when the logical solution actually fix it.

Logically, private is just another type of scope. The members should not be accesible outside of this. Put it in the spec, and you got another improvement over C++.

Lars Ivar Igesund

"David Medlock" <noone@nowhere.com> wrote in message news:dqoc32$6vs$1@digitaldaemon.com...
> 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.
>>
>> 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
>
> #2 is fullfilled here, but not #1.  If I cannot call or extend the private parts(hehe) then why should I see them?
>
> Walter, pragmatically this rule makes no sense for C++ or D.
> ( At least across modules it doesnt)
I agree.  Private members should be just that; invisible to all but those permitted to see them.  I mean, why should I care if my function has the same name as a private function defined in another module; it just doesn't play in to the grand scheme of things.
>
> -DavidM