Private visible?
Bruno Medeiros
brunodomedeirosATgmail at SPAM.com
Fri Jul 14 06:55:47 PDT 2006
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
More information about the Digitalmars-d
mailing list