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