www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - visibility bug

reply David Medlock <noone nowhere.com> writes:
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?
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


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.






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.
 




 
 

 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. 


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


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