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