Suggestion: Override protected with private

[buola]

Currently, a class cannot override a method with a more restricting access modifier. A public method can't be overridden with a private method, which makes sense because the method can be accessed by casting to the base class anyway.
However, this reason does not apply to protected methods, and it is a useful feature to be able to prevent access to protected methods (which can often be implementation details) when further subclassing.

For example:

class A {
   protected method() {}
}

class B extends A {
  private method() {}
}

Expected behavior:

Under the suggestion, it would compile correctly

Actual behavior:

Error because class B does not implement class A correctly

Something extra

If this is implemented, it could be good to have some mechanism by which class B can make the method private to further subclassing without having to provide an implementation.

[aluanhaddad]

A public method can't be overridden with a private method, which makes sense because the method can be accessed by casting to the base class anyway.

Doesn't the exact same logic apply within the hierarchy?

[buola]

@aluanhaddad No it doesn't, because protected methods can only be accessed in derived classes through 'this', and if a middle class has made it private, access through this would be forbidden. Consider the following code:

class A {
    protected f() {}
}

class B extends A {
    g() {
        this.f();
        var a: A = this;
        a.f(); //THIS IS AN ERROR, f() can only be accessed through 'this' within B.
    }
}

[mhegazy]

what about substitutability?

[buola]

@mhegazy I am not totally clear on the effects of access modifiers on substitutability... is it even possible to substitute one class with private methods with another? Shouldn't private and protected be almost identical in that case, since both kinds of methods are irrelevant in terms of interface implementation?

Can you find an example where this suggestion could cause an issue?

[RyanCavanaugh]

This doesn't seem to fit what other OOP languages do. It also creates the additional weirdness that there would be calls to a private method coming from outside the class itself, which should normally be disallowed.

[s3rb31]

What is going on here? Why is such a vital feature missing?

This doesn't seem to fit what other OOP languages do

How is that meant? Some OOP languages allow to override with a more restrictive access modifier, so this suggestion fits very well.

It also creates the additional weirdness that there would be calls to a private method coming from outside the class itself, which should normally be disallowed.

How? I don't seem to get it. Also, this does not seem to be a problem in other languages that allow what has been suggested. How they got around this "weirdness"?

'Working as Intended'

I think I missed the part where sombody explained why this is 'Working as Intended'. Especially for abstract base classes the suggested feature would make some things much easier and nicer.

Please reconsider adding support for this, at least for abstract classes.

[RyanCavanaugh]

The most OOP languages allow to override with a more restrictive access modifier, so this suggestion fits very well.

Examples?

[s3rb31]

The most OOP languages

Sorry. It was written hastily and is probably wrong. It should say some. I'll edit it above.

Examples?

I created a gist that demonstrates what I mean, it is written in C++.

But I noticed that it's not possible to override private methods in typescript so I have to apologize again. It would be great if it would be possible one day, though.

[RyanCavanaugh]

C++ is nearly unique among OOP languages in allowing this, and it is explicitly disclaimed as a bad idea:
https://isocpp.org/wiki/faq/proper-inheritance#hiding-inherited-public

If you want to override private methods, that's exactly what protected is for!