www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - visibility bug

reply David Medlock <noone nowhere.com> writes:
Manfred Nowak wrote:

 David Medlock wrote:

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

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?
Jan 10 2006
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"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.
Jan 15 2006
next sibling parent reply "Chris Miller" <chris dprogramming.com> writes:
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.
Jan 15 2006
next sibling parent jcc7 <jcc7_member pathlink.com> writes:
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
Jan 18 2006
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
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
Jan 18 2006
parent reply =?UTF-8?B?SmFyaS1NYXR0aSBNw6RrZWzDpA==?= <jmjmak utu.fi.invalid> writes:
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
Jan 19 2006
parent reply David Medlock <noone nowhere.com> writes:
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
Jan 19 2006
next sibling parent reply Don Clugston <dac nospam.com.au> writes:
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.
Jan 19 2006
parent Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
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.

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."
Jan 19 2006
prev sibling parent "Ameer Armaly" <ameer_armaly hotmail.com> writes:
"David Medlock" <noone nowhere.com> wrote in message 
news:dqoc32$6vs$1 digitaldaemon.com...
 Jari-Matti Mkel 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)

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 

Jan 19 2006
prev sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
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
Jan 19 2006