Private visible?

[Dave]

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