Shouldn't private methods be virtual too?

[Michel Fortin]

On 2008-06-10 19:02:13 -0400, Robert Fraser <fraserofthenight at gmail.com> said:

>> Making Base's method public or protected changes the output to 
>> "Derived.foo" as I'd expect.
> 
> I agree, but last time I asked this it seemed like an unwinnable battle 
> (everyone else said private should imply "final"). More controversial 
> was whether "package" should imply "final" (which it does now, but I 
> think it should not).

Ok, so we're two to think protection attributes should be orthogonal 
with the final attribute of a member function, although I can't say I'm 
strongly in favor of one or the other.

Package and private are pretty much the same thing: one makes the 
function accessible to the current module only, the other makes the 
function accessible to the current package only. If one has the side 
effect of making the function final, then the other should too if we 
are to preserve consistency.

As a side note, it's pretty amusing to see that even this compiles 
perfectly fine:

	class Base {
		final package void foo() { writefln("Base.foo"); }
	}

	class Derived : Base {
		override final package void foo() { writefln("Derived.foo"); }
	}

In Functions[1], it is said that "Functions marked as final may not be 
overridden in a derived class, unless they are also private", so I take 
it to mean that it is correct to override a final private function in 
derived class, and by extension this is true for package functions too, 
and thus, there are no bugs here. Funny, isnt' it?

[1]: http://www.digitalmars.com/d/2.0/function.html

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/