Module-level accessibility
Denis Koroskin
2korden at gmail.com
Mon Oct 4 11:29:38 PDT 2010
On Mon, 04 Oct 2010 22:26:17 +0400, Steven Schveighoffer
<schveiguy at yahoo.com> wrote:
> On Mon, 04 Oct 2010 14:13:52 -0400, Jonathan M Davis
> <jmdavisProg at gmx.com> wrote:
>
>> On Monday, October 04, 2010 10:37:53 Sean Kelly wrote:
>>> Andrei Alexandrescu Wrote:
>>> > There is still debate on the matter of private methods in interfaces.
>>> > Please bring up in this forum any additional pro and con arguments
>>> that
>>> > you might have.
>>>
>>> What debate? Private methods don't get a vtbl entry so I don't see
>>> how an
>>> interface could possibly require one, regardless of in-module
>>> visibility.
>>
>> Except that per TDPL private methods are _supposed_ to be in the vtable:
>> http://d.puremagic.com/issues/show_bug.cgi?id=4542
>>
>> The fact that they don't currently is definitely limiting. Personally,
>> I liked
>> what TDPL said about interfaces and private methods, and I don't know
>> what the
>> debate against them is. It all seemed quite sensible to me.
>>
>> Regardless, however, private methods really should be properly
>> polymorphic.
>
> What possible use case could private methods being polymorphic allow?
>
> A private method can only be called by the class that contains the
> implementation. Allowing base classes to call it makes no sense.
>
> Make the method protected, it gives the desired effect (including for
> the example in the bug report as stated by the original reporter).
>
> -Steve
module private;
import std.stdio;
class A
{
private void foo()
{
writeln("hi there");
}
}
class B : A
{
void test()
{
foo();
}
}
void main()
{
B b = new B();
b.test();
}
# dmd private.d && ./private
hi there!
More information about the Digitalmars-d
mailing list