www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Private visible?

reply Lucas Goss <lgoss007 gmail.com> writes:
Was there ever any resolve as to private being visible? I know Walter 
said he saw the value of private by default, but what about private 
being visible? It just seems to have dropped off the radar and I don't 
know if thats good or bad.

Lucas
Jul 13 2006
next sibling parent reply Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Lucas Goss wrote:

 Was there ever any resolve as to private being visible? I know Walter 
 said he saw the value of private by default, but what about private 
 being visible? It just seems to have dropped off the radar and I don't 
 know if thats good or bad.
 
 Lucas


The discussion about private being visible is pending on some research 
to be made about C++ accessibility rules. See this post and it's subthread:
news://news.digitalmars.com:119/e8nrtd$366$1 digitaldaemon.com
In particular Walter said:
"Thanks for the reference. This rule, however, long predates Daveed's 
involvement with C++. I want to do a little more research on this."


-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jul 13 2006
parent Lucas Goss <lgoss007 gmail.com> writes:
Bruno Medeiros wrote:

 
 The discussion about private being visible is pending on some research 
 to be made about C++ accessibility rules. See this post and it's subthread:
 news://news.digitalmars.com:119/e8nrtd$366$1 digitaldaemon.com
 In particular Walter said:
 "Thanks for the reference. This rule, however, long predates Daveed's 
 involvement with C++. I want to do a little more research on this."
 


Ah yes, now I remember. Thanks!

Lucas
Jul 13 2006
prev sibling next sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Lucas Goss wrote:


 Was there ever any resolve as to private being visible? I know Walter
 said he saw the value of private by default, but what about private
 being visible? It just seems to have dropped off the radar and I don't
 know if thats good or bad.
 
 Lucas


Did you mean accessible? Anyway, see Bruno's post, although I'm quite sure
it won't be forgotten by some of us ;)

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi
Jul 13 2006
parent reply Dave <Dave_member pathlink.com> writes:
Lars Ivar Igesund wrote:

 Lucas Goss wrote:


 Was there ever any resolve as to private being visible? I know Walter
 said he saw the value of private by default, but what about private
 being visible? It just seems to have dropped off the radar and I don't
 know if thats good or bad.

 Lucas


 Did you mean accessible? Anyway, see Bruno's post, although I'm quite 


sure

 it won't be forgotten by some of us ;)


Here's my take - feel free to correct:

- accessible: the symbol can be used (accessed). Must be visible as well 
for the lookup (I realize this is obvious).
- visible: the compiler considers the symbol during lookup even though 
it may not be accessible (maybe not so obvious).
Jul 13 2006
parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Dave wrote:


 Lars Ivar Igesund wrote:
  > Lucas Goss wrote:
  >
  >> Was there ever any resolve as to private being visible? I know Walter
  >> said he saw the value of private by default, but what about private
  >> being visible? It just seems to have dropped off the radar and I don't
  >> know if thats good or bad.
  >>
  >> Lucas
  >
  > Did you mean accessible? Anyway, see Bruno's post, although I'm quite
 sure
  > it won't be forgotten by some of us ;)
  >
 
 Here's my take - feel free to correct:
 
 - accessible: the symbol can be used (accessed). Must be visible as well
 for the lookup (I realize this is obvious).


Yes, that would be the sane thing, but one of the privacy problems in D, is
that it has been possible to access symbols by using the FQN, even though
it really isn't visible (declared to be private). As it is, I see no reason
to differ between visible and accessible, IMO they're two sides of the same
coin, or should be.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi
Jul 13 2006
parent reply Dave <Dave_member pathlink.com> writes:
Lars Ivar Igesund wrote:

 Dave wrote:
 

 Lars Ivar Igesund wrote:
  > Lucas Goss wrote:
  >
  >> Was there ever any resolve as to private being visible? I know Walter
  >> said he saw the value of private by default, but what about private
  >> being visible? It just seems to have dropped off the radar and I don't
  >> know if thats good or bad.
  >>
  >> Lucas
  >
  > Did you mean accessible? Anyway, see Bruno's post, although I'm quite
 sure
  > it won't be forgotten by some of us ;)
  >

 Here's my take - feel free to correct:

 - accessible: the symbol can be used (accessed). Must be visible as well
 for the lookup (I realize this is obvious).


 
 Yes, that would be the sane thing, but one of the privacy problems in D, is
 that it has been possible to access symbols by using the FQN, even though
 it really isn't visible (declared to be private). As it is, I see no reason
 to differ between visible and accessible, IMO they're two sides of the same
 coin, or should be.
 


See: http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/39754
Jul 13 2006
parent reply Dave <Dave_member pathlink.com> writes:
Dave wrote:

 Lars Ivar Igesund wrote:

 Dave wrote:


 Lars Ivar Igesund wrote:
  > Lucas Goss wrote:
  >
  >> Was there ever any resolve as to private being visible? I know 
 Walter
  >> said he saw the value of private by default, but what about private
  >> being visible? It just seems to have dropped off the radar and I 
 don't
  >> know if thats good or bad.
  >>
  >> Lucas
  >
  > Did you mean accessible? Anyway, see Bruno's post, although I'm quite
 sure
  > it won't be forgotten by some of us ;)
  >

 Here's my take - feel free to correct:

 - accessible: the symbol can be used (accessed). Must be visible as well
 for the lookup (I realize this is obvious).


 Yes, that would be the sane thing, but one of the privacy problems in 
 D, is
 that it has been possible to access symbols by using the FQN, even though
 it really isn't visible (declared to be private). As it is, I see no 
 reason
 to differ between visible and accessible, IMO they're two sides of the 
 same
 coin, or should be.


 
 See: http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/39754


A little too terse, I was... I tend to agree that they should be two 
sides of the same coin but the gist of it is that they aren't in D 
because they aren't in C++ for (possibly obscure) reasons that might not 
apply to D.

Everyone seems to agree that 'private' should not be accessible and the 
current behavior is a bug. What we're all wondering is if 'private' can 
also mean 'invisible' because that seems to be more intuitive. Than you 
don't have that extra level of complexity for lookup resolution and 
things like error messages describing a private interface.
Jul 13 2006
next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Dave wrote:

 Everyone seems to agree that 'private' should not be accessible and the 
 current behavior is a bug. What we're all wondering is if 'private' can 
 also mean 'invisible' because that seems to be more intuitive. Than you 
 don't have that extra level of complexity for lookup resolution and 
 things like error messages describing a private interface.


The original reason why private members would be visible but not 
accessible has been forgotten. However, there were some significant 
issues brought up with making them invisible:

1) function overloading - if various overloads of a function have 
different protections, different functions will be selected even though 
the same arguments are presented. This can be surprising when code is 
moved around. If they are visible, you'll get an error message instead 
of silently varying behavior.

2) function overloading - one could lose the ability to 'poison' an 
operation on certain argument types, because instead the private 
function will not be seen and another selected.

3) function overriding - if a private function in a derived class 
overrides a public one in a base class, this overriding will not happen 
if the private function is invisible. Not only does this break 
encapsulation, it prevents the design pattern of being able to 'poison' 
certain operations on a class.
Jul 13 2006
next sibling parent Dave <Dave_member pathlink.com> writes:
Walter Bright wrote:

 Dave wrote:

 Everyone seems to agree that 'private' should not be accessible and 
 the current behavior is a bug. What we're all wondering is if 
 'private' can also mean 'invisible' because that seems to be more 
 intuitive. Than you don't have that extra level of complexity for 
 lookup resolution and things like error messages describing a private 
 interface.


 
 The original reason why private members would be visible but not 
 accessible has been forgotten. However, there were some significant 
 issues brought up with making them invisible:
 
 1) function overloading - if various overloads of a function have 
 different protections, different functions will be selected even though 
 the same arguments are presented. This can be surprising when code is 
 moved around. If they are visible, you'll get an error message instead 
 of silently varying behavior.
 
 2) function overloading - one could lose the ability to 'poison' an 
 operation on certain argument types, because instead the private 
 function will not be seen and another selected.
 
 3) function overriding - if a private function in a derived class 
 overrides a public one in a base class, this overriding will not happen 
 if the private function is invisible. Not only does this break 
 encapsulation, it prevents the design pattern of being able to 'poison' 
 certain operations on a class.


Excellent - thank you.
Jul 13 2006
prev sibling next sibling parent Dave <Dave_member pathlink.com> writes:
Walter Bright wrote:

 Dave wrote:

 Everyone seems to agree that 'private' should not be accessible and 
 the current behavior is a bug. What we're all wondering is if 
 'private' can also mean 'invisible' because that seems to be more 
 intuitive. Than you don't have that extra level of complexity for 
 lookup resolution and things like error messages describing a private 
 interface.


 
 The original reason why private members would be visible but not 
 accessible has been forgotten. However, there were some significant 
 issues brought up with making them invisible:
 
 1) function overloading - if various overloads of a function have 
 different protections, different functions will be selected even though 
 the same arguments are presented. This can be surprising when code is 
 moved around. If they are visible, you'll get an error message instead 
 of silently varying behavior.
 
 2) function overloading - one could lose the ability to 'poison' an 
 operation on certain argument types, because instead the private 
 function will not be seen and another selected.
 
 3) function overriding - if a private function in a derived class 
 overrides a public one in a base class, this overriding will not happen 
 if the private function is invisible. Not only does this break 
 encapsulation, it prevents the design pattern of being able to 'poison' 
 certain operations on a class.


I don't wish to belabor this, but it would seem that the above great 
reasons for "visible but not accessible" conflict with the current 
behavior described here:

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/7649




Thanks,

- Dave
Jul 13 2006
prev sibling next sibling parent Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:

 Dave wrote:

 Everyone seems to agree that 'private' should not be accessible and 
 the current behavior is a bug. What we're all wondering is if 
 'private' can also mean 'invisible' because that seems to be more 
 intuitive. Than you don't have that extra level of complexity for 
 lookup resolution and things like error messages describing a private 
 interface.


 
 The original reason why private members would be visible but not 
 accessible has been forgotten. However, there were some significant 
 issues brought up with making them invisible:


Thank you very much for looking into this.


 1) function overloading - if various overloads of a function have 
 different protections, different functions will be selected even though 
 the same arguments are presented. This can be surprising when code is 
 moved around. If they are visible, you'll get an error message instead 
 of silently varying behavior.


I would assert that mixing protection attributes on overloads is Bad 
Programming.  Further, I think the principle of least surprise may not 
be a particularly strong argument here because the truly surprising 
behavior seems to be that private symbols are considered at all.  That 
the current C++ behavior has been elevated to the status of a newbie FAQ 
question is ample evidence here.


 2) function overloading - one could lose the ability to 'poison' an 
 operation on certain argument types, because instead the private 
 function will not be seen and another selected.


So basically intentionally exploiting the above behavior to prevent 
certain implicit conversions from occurring if the programmer does not 
have access to the base class (where it may be possible to add an 
'explicit' in C++).  Is this practice at all common?  And how much does 
it apply to D, given D's far simpler overload resolution mechanism?


 3) function overriding - if a private function in a derived class 
 overrides a public one in a base class, this overriding will not happen 
 if the private function is invisible. Not only does this break 
 encapsulation, it prevents the design pattern of being able to 'poison' 
 certain operations on a class.


Perhaps there should be some discussion of what 'private' means in D 
compared to C++.  For example, private functions in D are not 
overridable, but they are in C++.  I think this represents a somewhat 
fundamental departure from the C++ mindset, and perhaps warrants a 
different interpretation of how symbol resolution should be handled. 
Also, we have the benefit of weighing nearly 20 years of experience with 
the C++ mechanism, which I suspect had to be considered in purely 
hypothetical terms when the original decision was made.

In hindsight, does the C++ mechanism seem optimal for C++?  And is the 
language structure of D sufficiently similar to C++ that it is optimal 
for D, by extension?  I realize that these are difficult questions to 
answer, but I don't want to close the door on the idea just yet simply 
because the decision for C++ involved reasons that *may* also apply to 
D.  At the very least, it does seem clear that this behavior is 
confusing for novice programmers, and this is a red flag to me that the 
design may not be ideal.


Sean
Jul 13 2006
prev sibling next sibling parent reply Lucas Goss <lgoss007 gmail.com> writes:
Walter Bright wrote:

 
 The original reason why private members would be visible but not 
 accessible has been forgotten. However, there were some significant 
 issues brought up with making them invisible:
 
 1) function overloading - if various overloads of a function have 
 different protections, different functions will be selected even though 
 the same arguments are presented. This can be surprising when code is 
 moved around. If they are visible, you'll get an error message instead 
 of silently varying behavior.
 
 2) function overloading - one could lose the ability to 'poison' an 
 operation on certain argument types, because instead the private 
 function will not be seen and another selected.
 
 3) function overriding - if a private function in a derived class 
 overrides a public one in a base class, this overriding will not happen 
 if the private function is invisible. Not only does this break 
 encapsulation, it prevents the design pattern of being able to 'poison' 
 certain operations on a class.


Interesting. But if I use a third party library:

import lib.thirdparty;
...
commonFuncName() // error (declared in my module and in thirdparty)

I would be dumbfounded. Especially when I look at there documentation 
and there is no "commonFuncName".

I had some more thoughts... but I lost them in the midst of other 
responsibilities. I'll see if I can remember.

Lucas
Jul 13 2006
parent reply Dave <Dave_member pathlink.com> writes:
Lucas Goss wrote:

 Walter Bright wrote:

 The original reason why private members would be visible but not 




accessible has been forgotten. However, there were some significant 
issues brought up with making them invisible:

 1) function overloading - if various overloads of a function have 




different protections, different functions will be selected even though 
the same arguments are presented. This can be surprising when code is 
moved around. If they are visible, you'll get an error message instead 
of silently varying behavior.

 2) function overloading - one could lose the ability to 'poison' an 




operation on certain argument types, because instead the private 
function will not be seen and another selected.

 3) function overriding - if a private function in a derived class 




overrides a public one in a base class, this overriding will not happen 
if the private function is invisible. Not only does this break 
encapsulation, it prevents the design pattern of being able to 'poison' 
certain operations on a class.

 Interesting. But if I use a third party library:

 import lib.thirdparty;
 ...
 commonFuncName() // error (declared in my module and in thirdparty)

 I would be dumbfounded. Especially when I look at there documentation 


and there is no "commonFuncName".

 I had some more thoughts... but I lost them in the midst of other 


responsibilities. I'll see if I can remember.

 Lucas


It will look for and use the one in your module. If it is in your 
library that is also imported, then you'd get something like:

mylib.d(123): function mylib.baz conflicts with otherLib.baz at 
otherLib.d(456)

Then right now you could alias or hopefully soon use the new import 
syntax to disambiguate.

- Dave
Jul 13 2006
parent Lucas Goss <lgoss007 gmail.com> writes:
Dave wrote:

 
 It will look for and use the one in your module. If it is in your 
 library that is also imported, then you'd get something like:
 
 mylib.d(123): function mylib.baz conflicts with otherLib.baz at 
 otherLib.d(456)
 
 Then right now you could alias or hopefully soon use the new import 
 syntax to disambiguate.
 
 - Dave


That makes no sense to me (I understand what you're talking about, but 
it's like a gotcha). How could my public function conflict with a 
private function? I think the problem is that private functions are 
imported into the current namespace (I'm pretty sure that's been said 
before).

I remembered what I was thinking previously...
Is there any way to make private functions only be available by fully 
qualified name lookup and not imported into the current namespace? Or 
would that be too much work?

Lucas
Jul 13 2006
prev sibling next sibling parent Derek Parnell <derek nomail.afraid.org> writes:
On Thu, 13 Jul 2006 11:37:50 -0700, Walter Bright wrote:


 Dave wrote:

 Everyone seems to agree that 'private' should not be accessible and the 
 current behavior is a bug. What we're all wondering is if 'private' can 
 also mean 'invisible' because that seems to be more intuitive. Than you 
 don't have that extra level of complexity for lookup resolution and 
 things like error messages describing a private interface.


 
 The original reason why private members would be visible but not 
 accessible has been forgotten. However, there were some significant 
 issues brought up with making them invisible:
 
 1) function overloading - if various overloads of a function have 
 different protections, different functions will be selected even though 
 the same arguments are presented. This can be surprising when code is 
 moved around. If they are visible, you'll get an error message instead 
 of silently varying behavior.


Error messages are good, but don't let private stuff be accessible out of
scope. 
 

 2) function overloading - one could lose the ability to 'poison' an 
 operation on certain argument types, because instead the private 
 function will not be seen and another selected.


As it should. 'private' means 'this is mine and not yours so don't touch,
okay!?'


 3) function overriding - if a private function in a derived class 
 overrides a public one in a base class, this overriding will not happen 
 if the private function is invisible. Not only does this break 
 encapsulation, it prevents the design pattern of being able to 'poison' 
 certain operations on a class.


And yet to me this sounds like a good thing. 

Maybe I am confusing visibility and accessibility here, but in my simple
way of looking at things, 'private' should have the meaning nothing can
reference a private member by name except for things in the same scope and
things in the same module. In simple layman's terms, 'keep your grubby
hands off my member' ;-)

The current implementation of private in D is just about /perfect/, except
for the couple of acknowledged bugs and the error messages that reveal
private information.

Bug 1. FQN usage ignores privacy.
Bug 2. Function matching ignores privacy if a public name also exists.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocrity!"
14/07/2006 10:53:38 AM
Jul 13 2006
prev sibling next sibling parent reply Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Walter Bright wrote:

 Dave wrote:

 Everyone seems to agree that 'private' should not be accessible and 
 the current behavior is a bug. What we're all wondering is if 
 'private' can also mean 'invisible' because that seems to be more 
 intuitive. Than you don't have that extra level of complexity for 
 lookup resolution and things like error messages describing a private 
 interface.


 
 The original reason why private members would be visible but not 
 accessible has been forgotten. However, there were some significant 
 issues brought up with making them invisible:
 
 1) function overloading - if various overloads of a function have 
 different protections, different functions will be selected even though 
 the same arguments are presented. This can be surprising when code is 
 moved around. If they are visible, you'll get an error message instead 
 of silently varying behavior.
 


If I am using a library do I really need to get error messages about 
private functions from that library? To me this sounds not only like a 
bad design of that library but also of the language that allows it.

As others said mixing various protections on different functions of the 
same name is most of the times a bad design. But if it isn't and it is 
intentional, then what is the point in getting an error that something 
is private. If something is private isn't it then meant not to be seen?


 2) function overloading - one could lose the ability to 'poison' an 
 operation on certain argument types, because instead the private 
 function will not be seen and another selected.
 
 3) function overriding - if a private function in a derived class 
 overrides a public one in a base class, this overriding will not happen 
 if the private function is invisible. Not only does this break 
 encapsulation, it prevents the design pattern of being able to 'poison' 
 certain operations on a class.


Various 'poisoning' techniques sound a lot like C++ to me. There one can 
make classes that can not be constructed, can not be inherited from, can 
not be passed by value, cannot be allocated on stack and many different 
things by making something that is private. But are these techniques 
realistic or even possible in D?

I don't know what to do about 3) but is this the way to do things in D 
as is in C++?
Jul 14 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Ivan Senji wrote:

 Various 'poisoning' techniques sound a lot like C++ to me. There one can 
 make classes that can not be constructed, can not be inherited from, can 
 not be passed by value, cannot be allocated on stack and many different 
 things by making something that is private. But are these techniques 
 realistic or even possible in D?


Sometimes it is valuable to be able to say "you can't do this operation 
with this type". I don't see why this ability should be restricted to C++.
Jul 14 2006
next sibling parent reply Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Walter Bright wrote:

 Ivan Senji wrote:

 Various 'poisoning' techniques sound a lot like C++ to me. There one 
 can make classes that can not be constructed, can not be inherited 
 from, can not be passed by value, cannot be allocated on stack and 
 many different things by making something that is private. But are 
 these techniques realistic or even possible in D?


 
 Sometimes it is valuable to be able to say "you can't do this operation 
 with this type". I don't see why this ability should be restricted to C++.


OK, for a type, but would it be inconsistent if private was handled 
different in class and module level?

I didn't mean it should be restricted to C++ but was rather wondering if 
there are other/better ways in D?
Jul 14 2006
parent Walter Bright <newshound digitalmars.com> writes:
Ivan Senji wrote:

 Walter Bright wrote:

 Ivan Senji wrote:

 Various 'poisoning' techniques sound a lot like C++ to me. There one 
 can make classes that can not be constructed, can not be inherited 
 from, can not be passed by value, cannot be allocated on stack and 
 many different things by making something that is private. But are 
 these techniques realistic or even possible in D?


 Sometimes it is valuable to be able to say "you can't do this 
 operation with this type". I don't see why this ability should be 
 restricted to C++.


 
 OK, for a type, but would it be inconsistent if private was handled 
 different in class and module level?
 
 I didn't mean it should be restricted to C++ but was rather wondering if 
 there are other/better ways in D?


I don't know of a better way.
Jul 14 2006
prev sibling next sibling parent Don Clugston <dac nospam.com.au> writes:
Walter Bright wrote:

 Ivan Senji wrote:

 Various 'poisoning' techniques sound a lot like C++ to me. There one 
 can make classes that can not be constructed, can not be inherited 
 from, can not be passed by value, cannot be allocated on stack and 
 many different things by making something that is private. But are 
 these techniques realistic or even possible in D?


 
 Sometimes it is valuable to be able to say "you can't do this operation 
 with this type". I don't see why this ability should be restricted to C++.


Seems to me that it's a bit of a hack to use private for that purpose.
FWIW, you can also use deprecated{} to poison functions (though of 
course it doesn't work if -d is enabled). Of course this is a hack as 
well, but interestingly it catches internal use of that function, which 
AFAIK 'private' does not.

class Something {
deprecated {
   bool opEquals(Something q) { return false; }
}
}

And if IFTI worked for operators, you could write:

class Something {
   bool opEquals(A) (A q) {
	static assert(0,
      "You can't do == with type Something, because ...");
   }
}
Jul 14 2006
prev sibling next sibling parent reply "Derek Parnell" <derek psych.ward> writes:
On Fri, 14 Jul 2006 19:30:19 +1000, Walter Bright  
<newshound digitalmars.com> wrote:


 Ivan Senji wrote:

 Various 'poisoning' techniques sound a lot like C++ to me. There one  
 can make classes that can not be constructed, can not be inherited  
 from, can not be passed by value, cannot be allocated on stack and many  
 different things by making something that is private. But are these  
 techniques realistic or even possible in D?


 Sometimes it is valuable to be able to say "you can't do this operation  
 with this type". I don't see why this ability should be restricted to  
 C++.


In that case, why not directly support this concept in the language rather  
than use 'tricks' or side-effects to do it. If it a worthy thing then say  
so.

-- 
Derek Parnell
Melbourne, Australia
Jul 14 2006
parent Chad J <gamerChad _spamIsBad_gmail.com> writes:
Derek Parnell wrote:

 On Fri, 14 Jul 2006 19:30:19 +1000, Walter Bright  
 <newshound digitalmars.com> wrote:
 

 Ivan Senji wrote:


 Various 'poisoning' techniques sound a lot like C++ to me. There one  
 can make classes that can not be constructed, can not be inherited  
 from, can not be passed by value, cannot be allocated on stack and 
 many  different things by making something that is private. But are 
 these  techniques realistic or even possible in D?



 Sometimes it is valuable to be able to say "you can't do this 
 operation  with this type". I don't see why this ability should be 
 restricted to  C++.


 
 
 In that case, why not directly support this concept in the language 
 rather  than use 'tricks' or side-effects to do it. If it a worthy thing 
 then say  so.
 


Just out of personal preference I agree with Derek here.

To me it seems unintuitive to make private visible.  My typical use of 
private is intended to hide something, not just make it inaccessable. 
Would there even be a way to make an identifier invisible?  Anyhow, I'd 
rather private be invisible, and add a "poisoned" keyword or somesuch 
(better name?).

Overloads by protection also seem dubious IMO.
Jul 14 2006
prev sibling parent reply Lucas Goss <lgoss007 gmail.com> writes:
Walter Bright wrote:

 
 Sometimes it is valuable to be able to say "you can't do this operation 
 with this type". I don't see why this ability should be restricted to C++.


Can someone come up with an example or explain why this would be 
valuable? To make sure we're on the same page, we're talking about:

----
class Base {
   public:
     virtual int Number() = 0;
};
...
class Child : public Base {
   private:
     int Number() { return 1; }
};
...
Child c;
int num = c.Number(); //error: cannot access private member
Child* cp = new Child();
num = cp->Number(); //error: cannot access private member
Base* bp = new Child();
num = bp->Number(); // num = 1

----
Is there an example where you can't subvert the poison? In this case 
can't we get a pointer to the base class which returns what the child 
class didn't want to give us (private Number)?

...Added to wiki to get better overview (it's easier for me to see 
rather than jumping all over the newsgroup. Feel free to edit and 
consolidate views into concrete and concise arguments. I'm starting to 
feel like a secretary... :)

http://www.prowiki.org/wiki4d/wiki.cgi?PrivateIssues

Lucas
Jul 14 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Lucas Goss wrote:

 Walter Bright wrote:

 Sometimes it is valuable to be able to say "you can't do this 
 operation with this type". I don't see why this ability should be 
 restricted to C++.


 
 Can someone come up with an example or explain why this would be 
 valuable? To make sure we're on the same page, we're talking about:
 
 ----
 class Base {
   public:
     virtual int Number() = 0;
 };
 ...
 class Child : public Base {
   private:
     int Number() { return 1; }
 };


I think it's a bug that the compiler allows this. It should be illegal 
code, because it breaks encapsulation.
Jul 14 2006
next sibling parent reply Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Walter Bright wrote:

 Lucas Goss wrote:

 Walter Bright wrote:

 Sometimes it is valuable to be able to say "you can't do this 
 operation with this type". I don't see why this ability should be 
 restricted to C++.


 Can someone come up with an example or explain why this would be 
 valuable? To make sure we're on the same page, we're talking about:

 ----
 class Base {
   public:
     virtual int Number() = 0;
 };
 ...
 class Child : public Base {
   private:
     int Number() { return 1; }
 };


 
 I think it's a bug that the compiler allows this. It should be illegal 
 code, because it breaks encapsulation.


Good. That should be documented in the spec then, that isn't mentioned 
anywhere, as far as we know.

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jul 15 2006
parent reply Lucas Goss <lgoss007 gmail.com> writes:
Bruno Medeiros wrote:

 
 Good. That should be documented in the spec then, that isn't mentioned 
 anywhere, as far as we know.
 


Uh, that was C++ code, sorry I didn't make it clear.

Lucas
Jul 15 2006
parent Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Lucas Goss wrote:

 Bruno Medeiros wrote:

 Good. That should be documented in the spec then, that isn't mentioned 
 anywhere, as far as we know.


 
 Uh, that was C++ code, sorry I didn't make it clear.
 
 Lucas


Yes, but what Walter said (about the spec) was referring to D, even if 
your post was a C++ code.

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jul 16 2006
prev sibling parent reply Lucas Goss <lgoss007 gmail.com> writes:
Walter Bright wrote:

 Lucas Goss wrote:

 Walter Bright wrote:

 Sometimes it is valuable to be able to say "you can't do this 
 operation with this type". I don't see why this ability should be 
 restricted to C++.


 Can someone come up with an example or explain why this would be 
 valuable? To make sure we're on the same page, we're talking about:

 ----
 class Base {
   public:
     virtual int Number() = 0;
 };
 ...
 class Child : public Base {
   private:
     int Number() { return 1; }
 };


 
 I think it's a bug that the compiler allows this. It should be illegal 
 code, because it breaks encapsulation.


Um, maybe I didn't make it clear enough, or maybe I'm not understanding. 
The above is C++ code that went with this code:

(1)
Child c;
int num = c.Number(); //error: cannot access private member

(2)
Child* cp = new Child();
num = cp->Number(); //error: cannot access private member

(3)
Base* bp = new Child();
num = bp->Number(); // num = 1

So the compiler does error with the first two attempts, but the third 
compiles and runs fine. I was just trying to find an example of 
'poisoning' a base class that you mentioned. To me it doesn't sound like 

practice). I just wanted to make sure I'm understanding correctly.

Lucas
Jul 15 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Lucas Goss wrote:

 So the compiler does error with the first two attempts, but the third 
 compiles and runs fine.


Yes, it is C++ and is perfectly legal C++. A more interesting question 
is should it be legal? I posed the question in comp.lang.c++.moderated, 
and got a couple of interesting answers.
Jul 15 2006
next sibling parent David Medlock <noone nowhere.com> writes:
Walter Bright wrote:

 Lucas Goss wrote:
 

 So the compiler does error with the first two attempts, but the third 
 compiles and runs fine.


 
 
 Yes, it is C++ and is perfectly legal C++. A more interesting question 
 is should it be legal? I posed the question in comp.lang.c++.moderated, 
 and got a couple of interesting answers.


in Java you cannot override a method with a more protected access.  I 
consider it a safeguard, so that I do not get caught in a lattice of 
protection attributes and inheritance.

-DavidM
Jul 15 2006
prev sibling next sibling parent reply Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Walter Bright wrote:

 Lucas Goss wrote:

 So the compiler does error with the first two attempts, but the third 
 compiles and runs fine.


 
 Yes, it is C++ and is perfectly legal C++. A more interesting question 
 is should it be legal? I posed the question in comp.lang.c++.moderated, 
 and got a couple of interesting answers.


Could you post the link to that discussion? (I don't think I can easily 
find it myself)


disallows to change the protection in any way. Java has a covariant 
behavior, as mentioned by David. )

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jul 16 2006
next sibling parent David Medlock <noone nowhere.com> writes:
Bruno Medeiros wrote:

 Walter Bright wrote:
 

 Lucas Goss wrote:


 So the compiler does error with the first two attempts, but the third 
 compiles and runs fine.



 Yes, it is C++ and is perfectly legal C++. A more interesting question 
 is should it be legal? I posed the question in 
 comp.lang.c++.moderated, and got a couple of interesting answers.


 
 
 Could you post the link to that discussion? (I don't think I can easily 
 find it myself)
 

 disallows to change the protection in any way. Java has a covariant 
 behavior, as mentioned by David. )
 


Not to mention you can always throw an Exception in the disallowed 
operations, so I don't see this as a great usage of protection attributes.

-DavidM
Jul 16 2006
prev sibling parent Walter Bright <newshound digitalmars.com> writes:
Bruno Medeiros wrote:

 Could you post the link to that discussion? (I don't think I can easily 
 find it myself)


It's entitled:

	Restricting access should be illegal?

posted 7/15/2006 3:38 AM on comp.lang.c++.moderated.

It's an ongoing discussion, so it'd be premature to summarize here.
Jul 16 2006
prev sibling parent Lucas Goss <lgoss007 gmail.com> writes:
Walter Bright wrote:

 Lucas Goss wrote:

 So the compiler does error with the first two attempts, but the third 
 compiles and runs fine.


 
 Yes, it is C++ and is perfectly legal C++. A more interesting question 
 is should it be legal? I posed the question in comp.lang.c++.moderated, 
 and got a couple of interesting answers.


That's what I'm trying to discover, is there a good reason it should be 
legal. I found the thread here (for those interested).


Lucas
Jul 16 2006
prev sibling next sibling parent reply xs0 <xs0 xs0.com> writes:
 The original reason why private members would be visible but not 
 accessible has been forgotten. However, there were some significant 
 issues brought up with making them invisible:
 
 1) function overloading - if various overloads of a function have 
 different protections, different functions will be selected even though 
 the same arguments are presented. This can be surprising when code is 
 moved around. If they are visible, you'll get an error message instead 
 of silently varying behavior.



 2) function overloading - one could lose the ability to 'poison' an 
 operation on certain argument types, because instead the private 
 function will not be seen and another selected.



 3) function overriding - if a private function in a derived class 
 overrides a public one in a base class, this overriding will not happen 
 if the private function is invisible. Not only does this break 
 encapsulation, it prevents the design pattern of being able to 'poison' 
 certain operations on a class.


Consider

class Number {
     public void setVal(int val) { ... }
     public void setVal(long val) { ... }
}

class IntNumber : Number {
     public void setVal(int val) { ... }
     private void setVal(long val) { assert(0); }
}

Number a = new IntNumber();
a.setVal(10L);

Now, not only does the last line compile, it also calls the wrong 
function and fails to fail. There is no poisoning or whatever, and the 
author's belief that he achieved something by declaring something 
private is misguided. Furthermore, allowing the private declaration 
above means allowing broking inherited interfaces, practically always a bug.

Reducing visibility should be forbidden, as it doesn't even work and 
leads to bugs.

Private members should be totally invisible, because that's the point of 
marking them private.

As for overloading issues, as far as I am concerned, feel free to 
require all methods with the same name to have the same protection; 
anything else is poor taste anyway.


xs0
Jul 14 2006
next sibling parent reply =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
xs0 wrote:

 class Number {
     public void setVal(int val) { ... }
     public void setVal(long val) { ... }
 }
 
 class IntNumber : Number {
     public void setVal(int val) { ... }
     private void setVal(long val) { assert(0); }
 }
 
 Number a = new IntNumber();
 a.setVal(10L);
 
 Now, not only does the last line compile, it also calls the wrong
 function and fails to fail.


And casting back to IntNumber makes it again private. No OOP language
should do that. It's against the rules of polymorphism.


 Private members should be totally invisible, because that's the point of
 marking them private.


But then the compiler loses the ability to make intelligent error
messages, right?


 As for overloading issues, as far as I am concerned, feel free to
 require all methods with the same name to have the same protection;
 anything else is poor taste anyway.


Really? Then how do you hide the previous method implementation?

class A {
  protected pm() { ... }
}
class B : A {
  // ugly, isn't it :(
  protected pm() { assert(0); /* subclasses: do not use this */ }
  public pm2() { super.pm(); ... }
}

vs.

class A {
  protected pm() { ... }
}
class B : A {
  public pm() { super.pm(); ... }
}

-- 
Jari-Matti
Jul 14 2006
next sibling parent Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Jari-Matti Mäkelä wrote:

 xs0 wrote:

 class Number {
     public void setVal(int val) { ... }
     public void setVal(long val) { ... }
 }

 class IntNumber : Number {
     public void setVal(int val) { ... }
     private void setVal(long val) { assert(0); }
 }

 Number a = new IntNumber();
 a.setVal(10L);

 Now, not only does the last line compile, it also calls the wrong
 function and fails to fail.


 
 And casting back to IntNumber makes it again private. No OOP language
 should do that. It's against the rules of polymorphism.
 


Agreed, it does seem that contravariant (method) protection levels 
should not be allowed.


 

 As for overloading issues, as far as I am concerned, feel free to
 require all methods with the same name to have the same protection;
 anything else is poor taste anyway.


 
 Really? Then how do you hide the previous method implementation?
 
 class A {
   protected pm() { ... }
 }
 class B : A {
   // ugly, isn't it :(
   protected pm() { assert(0); /* subclasses: do not use this */ }
   public pm2() { super.pm(); ... }
 }
 
 vs.
 
 class A {
   protected pm() { ... }
 }
 class B : A {
   public pm() { super.pm(); ... }
 }
 


He said overload, not override.

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jul 14 2006
prev sibling parent reply xs0 <xs0 xs0.com> writes:
 Private members should be totally invisible, because that's the point of
 marking them private.


 
 But then the compiler loses the ability to make intelligent error
 messages, right?


No, the compiler obviously still sees them.. But as far as things like 
overload resolution are concerned, the end result should be the same as 
if they didn't exist (note that this point is moot if they're all 
required to be at the same visibility)



 As for overloading issues, as far as I am concerned, feel free to
 require all methods with the same name to have the same protection;
 anything else is poor taste anyway.


 
 Really? Then how do you hide the previous method implementation?


I'm not sure what you're asking here.. You can override methods as 
normal. You can also increase visibility, if you want, but once you do 
it for one method named "foo", you have to do it for all other methods 
named "foo" as well.


 class A {
   protected pm() { ... }
 }
 class B : A {
   // ugly, isn't it :(
   protected pm() { assert(0); /* subclasses: do not use this */ }
   public pm2() { super.pm(); ... }
 }


ugly indeed, but not necessary :)


 class A {
   protected pm() { ... }
 }
 class B : A {
   public pm() { super.pm(); ... }
 }


All methods in class B called "pm" have the same visibility, so no 
problem...


xs0
Jul 14 2006
parent =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
xs0 wrote:

 As for overloading issues, as far as I am concerned, feel free to
 require all methods with the same name to have the same protection;
 anything else is poor taste anyway.


 Really? Then how do you hide the previous method implementation?


 
 I'm not sure what you're asking here.. You can override methods as
 normal. You can also increase visibility, if you want, but once you do
 it for one method named "foo", you have to do it for all other methods
 named "foo" as well.


Sorry, my bad. I was still thinking about the overrides.

Combining overriding + overloading may lead to very confusing code.
Personally I definitely wouldn't want to touch any C++ code that
overloads ints, longs and/or chars and overrides them with methods
having totally random visibility unless somebody was pointing at me with
a loaded shotgun.

Luckily overloading is a bit easier in D. Still, it should first check
that all overrides are sane and nothing weird happens when an object is
called through different base classes/interfaces.

-- 
Jari-Matti
Jul 14 2006
prev sibling parent reply Dave <Dave_member pathlink.com> writes:
xs0 wrote:

 

 The original reason why private members would be visible but not 
 accessible has been forgotten. However, there were some significant 
 issues brought up with making them invisible:

 1) function overloading - if various overloads of a function have 
 different protections, different functions will be selected even 
 though the same arguments are presented. This can be surprising when 
 code is moved around. If they are visible, you'll get an error message 
 instead of silently varying behavior.


 

 2) function overloading - one could lose the ability to 'poison' an 
 operation on certain argument types, because instead the private 
 function will not be seen and another selected.


 

 3) function overriding - if a private function in a derived class 
 overrides a public one in a base class, this overriding will not 
 happen if the private function is invisible. Not only does this break 
 encapsulation, it prevents the design pattern of being able to 
 'poison' certain operations on a class.


 
 Consider
 
 class Number {
     public void setVal(int val) { ... }
     public void setVal(long val) { ... }
 }
 
 class IntNumber : Number {
     public void setVal(int val) { ... }
     private void setVal(long val) { assert(0); }
 }
 
 Number a = new IntNumber();
 a.setVal(10L);


With 162, it _does_ fail to compile if you move the class definitions to 
another module. If the code is all in the same module, then the assert 
trips. Both of these seem to work Ok to me.


 
 Now, not only does the last line compile, it also calls the wrong 
 function and fails to fail. There is no poisoning or whatever, and the 
 author's belief that he achieved something by declaring something 
 private is misguided. Furthermore, allowing the private declaration 
 above means allowing broking inherited interfaces, practically always a 
 bug.
 
 Reducing visibility should be forbidden, as it doesn't even work and 
 leads to bugs.
 
 Private members should be totally invisible, because that's the point of 
 marking them private.
 


IMHO, that may be a little strong...

IIRC 'protection' is universally termed "access protection" - not just 
in D but when describing OOP protection generically or specifically for 
almost any other OOP language. In other words, it specifies 'access' not 
'visibility'.

I think this is the first time I've really run into big 'visibility' 
concerns and can't recall 'visibility' by itself requiring a redesign of 
either the library or client code that I've written or used. But I do 
tend to agree it can be unintuitive, and if things could also be made 
'invisible' and not break/limit other things than I'm all for it.

If it weren't for the two bugs regarding private module members not 
really being private, I wonder if this topic would even be a big concern 
right now.


 As for overloading issues, as far as I am concerned, feel free to 
 require all methods with the same name to have the same protection; 
 anything else is poor taste anyway.
 
 
 xs0
Jul 14 2006
parent reply xs0 <xs0 xs0.com> writes:
 class Number {
     public void setVal(int val) { ... }
     public void setVal(long val) { ... }
 }

 class IntNumber : Number {
     public void setVal(int val) { ... }
     private void setVal(long val) { assert(0); }
 }

 Number a = new IntNumber();
 a.setVal(10L);


 
 With 162, it _does_ fail to compile if you move the class definitions to 
 another module. If the code is all in the same module, then the assert 
 trips. Both of these seem to work Ok to me.


Are you sure? I just checked again and the assert doesn't trip, nor does 
it fail to compile. Here is the exact code I used:

module main;

import ba;

void main()
{
	Number a = new IntNumber();
	a.setVal(10L);
}
==================
module ba;

class Number {
     public void setVal(int val) { }
     public void setVal(long val) { }
}

class IntNumber : Number {
     public void setVal(int val) { }
     private void setVal(long val) { assert(0); }
}



 Reducing visibility should be forbidden, as it doesn't even work and 
 leads to bugs.

 Private members should be totally invisible, because that's the point 
 of marking them private.


 
 IMHO, that may be a little strong...
 
 IIRC 'protection' is universally termed "access protection" - not just 
 in D but when describing OOP protection generically or specifically for 
 almost any other OOP language. In other words, it specifies 'access' not 
 'visibility'.


Well, I've no idea what term is the exactly right one to use, but I 
wanted to say that outside their defining module, private stuff should 
have no effects at all on any other code, as if it wasn't there at all.


xs0
Jul 14 2006
parent Dave <Dave_member pathlink.com> writes:
xs0 wrote:

 

 class Number {
     public void setVal(int val) { ... }
     public void setVal(long val) { ... }
 }

 class IntNumber : Number {
     public void setVal(int val) { ... }
     private void setVal(long val) { assert(0); }
 }

 Number a = new IntNumber();
 a.setVal(10L);


 With 162, it _does_ fail to compile if you move the class definitions 
 to another module. If the code is all in the same module, then the 
 assert trips. Both of these seem to work Ok to me.


 
 Are you sure? I just checked again and the assert doesn't trip, nor does 
 it fail to compile. Here is the exact code I used:
 
 module main;
 
 import ba;
 
 void main()
 {
     Number a = new IntNumber();
     a.setVal(10L);
 }
 ==================
 module ba;
 
 class Number {
     public void setVal(int val) { }
     public void setVal(long val) { }
 }
 
 class IntNumber : Number {
     public void setVal(int val) { }
     private void setVal(long val) { assert(0); }
 }
 


Ahhh, I used 'IntNumber a = new IntNumber();' not 'Number a = new 
IntNumber();' (I didn't copy 'n paste).

But 'a' is a 'Number' and not an 'IntNumber'. D has the same behavior as 
the equivalent C++ in this case.

If I cast: (cast(IntNumber)a).setVal(10L); with your code then I get the 
expected results too.


 

 Reducing visibility should be forbidden, as it doesn't even work and 
 leads to bugs.

 Private members should be totally invisible, because that's the point 
 of marking them private.


 IMHO, that may be a little strong...

 IIRC 'protection' is universally termed "access protection" - not just 
 in D but when describing OOP protection generically or specifically 
 for almost any other OOP language. In other words, it specifies 
 'access' not 'visibility'.


 
 Well, I've no idea what term is the exactly right one to use, but I 
 wanted to say that outside their defining module, private stuff should 
 have no effects at all on any other code, as if it wasn't there at all.
 
 
 xs0
Jul 14 2006
prev sibling parent Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Walter Bright wrote:

 Dave wrote:

 Everyone seems to agree that 'private' should not be accessible and 
 the current behavior is a bug. What we're all wondering is if 
 'private' can also mean 'invisible' because that seems to be more 
 intuitive. Than you don't have that extra level of complexity for 
 lookup resolution and things like error messages describing a private 
 interface.


 
 The original reason why private members would be visible but not 
 accessible has been forgotten. However, there were some significant 
 issues brought up with making them invisible:
 
 1) function overloading - if various overloads of a function have 
 different protections, different functions will be selected even though 
 the same arguments are presented. This can be surprising when code is 
 moved around. If they are visible, you'll get an error message instead 
 of silently varying behavior.
 


Perhaps do as suggested before, disallow overloads with different 
protections?


 2) function overloading - one could lose the ability to 'poison' an 
 operation on certain argument types, because instead the private 
 function will not be seen and another selected.
 


I didn't get this case, what is this 'poison' design pattern?


 3) function overriding - if a private function in a derived class 
 overrides a public one in a base class, this overriding will not happen 
 if the private function is invisible. Not only does this break 
 encapsulation, it prevents the design pattern of being able to 'poison' 
 certain operations on a class.


Same question as above.

But regardless of the answer, perhaps D should disallow the strictening 
of protection levels (i.e., allow only wider protection), since that 
seems to be inconsistent behavior from an OO and subtyping point of 
view? This issue was discussed a bit in a recent D.bugs thread:
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/7649
(news://news.digitalmars.com:119/e7jv87$1a8g$1 digitaldaemon.com)
In particular it was stated that the spec is a bit vague in what kind of 
behavior is allowed (in regards to overriding and protection levels).

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jul 14 2006
prev sibling parent reply =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
Dave wrote:

 Dave wrote:

 Lars Ivar Igesund wrote:

 Dave wrote:


 Lars Ivar Igesund wrote:
  > Lucas Goss wrote:
  >
  >> Was there ever any resolve as to private being visible? I know
 Walter
  >> said he saw the value of private by default, but what about private
  >> being visible? It just seems to have dropped off the radar and I
 don't
  >> know if thats good or bad.
  >>
  >> Lucas
  >
  > Did you mean accessible? Anyway, see Bruno's post, although I'm
 quite
 sure
  > it won't be forgotten by some of us ;)
  >

 Here's my take - feel free to correct:

 - accessible: the symbol can be used (accessed). Must be visible as
 well
 for the lookup (I realize this is obvious).


 Yes, that would be the sane thing, but one of the privacy problems in
 D, is
 that it has been possible to access symbols by using the FQN, even
 though
 it really isn't visible (declared to be private). As it is, I see no
 reason
 to differ between visible and accessible, IMO they're two sides of
 the same
 coin, or should be.


 See: http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/39754


 
 A little too terse, I was... I tend to agree that they should be two
 sides of the same coin but the gist of it is that they aren't in D
 because they aren't in C++ for (possibly obscure) reasons that might not
 apply to D.
 
 Everyone seems to agree that 'private' should not be accessible and the
 current behavior is a bug.


IMO 'private' works quite well now. The only problem is that there's no
access control when using FQN's. I haven't yet tested all the special
cases like inner classes, but overall it seems to be better now in 0.162.


 What we're all wondering is if 'private' can
 also mean 'invisible' because that seems to be more intuitive. Than you
 don't have that extra level of complexity for lookup resolution and
 things like error messages describing a private interface.


IMO more compiler logic here makes programmer more productive. I find
this situation analogous to includes in C/C++ vs. imports in D. C/C++ is
lacking a lot of great functionality there. I'm not that sure if it's
that much slower to handle both levels of accessibility separately, but
I can surely see the benefits arising from better compiler error messages.

AFAICS the only argument against current behavior is that people think
it's somehow "easier" to implement a compiler that does only visibility
checks. Of course it's a bit annoying to see that this "bug" has been
open for many years now, but Walter has been long busy working on the
cool new features that have added much to the value of D. But now that D
is reaching stable, maybe it's finally time to find a solution to these.
IMO fixing the FQN's would be enough. Walter, could it be possible to
implement these checks as a special case for FQN's if it's too difficult
to form some general rules for the order of phases (access control, name
lookup)?

-- 
Jari-Matti
Jul 13 2006
parent reply Dave <Dave_member pathlink.com> writes:
Jari-Matti Mäkelä wrote:

 Dave wrote:

 Dave wrote:

 Lars Ivar Igesund wrote:

 Dave wrote:


 Lars Ivar Igesund wrote:
  > Lucas Goss wrote:
  >
  >> Was there ever any resolve as to private being visible? I know
 Walter
  >> said he saw the value of private by default, but what about private
  >> being visible? It just seems to have dropped off the radar and I
 don't
  >> know if thats good or bad.
  >>
  >> Lucas
  >
  > Did you mean accessible? Anyway, see Bruno's post, although I'm
 quite
 sure
  > it won't be forgotten by some of us ;)
  >

 Here's my take - feel free to correct:

 - accessible: the symbol can be used (accessed). Must be visible as
 well
 for the lookup (I realize this is obvious).


 Yes, that would be the sane thing, but one of the privacy problems in
 D, is
 that it has been possible to access symbols by using the FQN, even
 though
 it really isn't visible (declared to be private). As it is, I see no
 reason
 to differ between visible and accessible, IMO they're two sides of
 the same
 coin, or should be.


 See: http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/39754


 A little too terse, I was... I tend to agree that they should be two
 sides of the same coin but the gist of it is that they aren't in D
 because they aren't in C++ for (possibly obscure) reasons that might not
 apply to D.

 Everyone seems to agree that 'private' should not be accessible and the
 current behavior is a bug.


 
 IMO 'private' works quite well now. The only problem is that there's no
 access control when using FQN's. I haven't yet tested all the special
 cases like inner classes, but overall it seems to be better now in 0.162.
 

 What we're all wondering is if 'private' can
 also mean 'invisible' because that seems to be more intuitive. Than you
 don't have that extra level of complexity for lookup resolution and
 things like error messages describing a private interface.


 
 IMO more compiler logic here makes programmer more productive. I find
 this situation analogous to includes in C/C++ vs. imports in D. C/C++ is
 lacking a lot of great functionality there. I'm not that sure if it's
 that much slower to handle both levels of accessibility separately, but
 I can surely see the benefits arising from better compiler error messages.
 
 AFAICS the only argument against current behavior is that people think
 it's somehow "easier" to implement a compiler that does only visibility
 checks. Of course it's a bit annoying to see that this "bug" has been
 open for many years now, but Walter has been long busy working on the
 cool new features that have added much to the value of D. But now that D
 is reaching stable, maybe it's finally time to find a solution to these.
 IMO fixing the FQN's would be enough. Walter, could it be possible to
 implement these checks as a special case for FQN's if it's too difficult
 to form some general rules for the order of phases (access control, name
 lookup)?
 


Here's an example that doesn't require FQN to expose the bug:

module foo;
void bar(int i)
{
   printf("bar(int)\n");
}
private void bar(char[] str)
{
   printf("bar(char[]): %s\n",cast(char*)str);
}

module main;
import foo;
void main()
{
   bar("test");
}

If you comment bar(int) out then it issues the correct compiler message 
otherwise it happily prints what you'd expect if bar(char[]) was not 
private.

- Dave
Jul 13 2006
parent =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
Dave wrote:

 Here's an example that doesn't require FQN to expose the bug:
 
 module foo;
 void bar(int i)
 {
   printf("bar(int)\n");
 }
 private void bar(char[] str)
 {
   printf("bar(char[]): %s\n",cast(char*)str);
 }
 
 module main;
 import foo;
 void main()
 {
   bar("test");
 }
 
 If you comment bar(int) out then it issues the correct compiler message
 otherwise it happily prints what you'd expect if bar(char[]) was not
 private.


Doh, didn't see that :">

-- 
Jari-Matti
Jul 13 2006
prev sibling parent Michael <Michael_member pathlink.com> writes:


In article <e95nsi$2vkf$1 digitaldaemon.com>, Lucas Goss says...

Was there ever any resolve as to private being visible? I know Walter 
said he saw the value of private by default, but what about private 
being visible? It just seems to have dropped off the radar and I don't 
know if thats good or bad.

Lucas
Jul 14 2006