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

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

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

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

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

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

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

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.

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.

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.