Private visible?

Derek Parnell derek at nomail.afraid.org
Thu Jul 13 18:11:15 PDT 2006


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



More information about the Digitalmars-d mailing list