protected and mix-ins don’t work together

[jbaron]

If you implement (so not extend) a class that has protected methods, you always get an error (typically used for a mix-in like pattern)

Either you implement the method, but then the compiler complaints that you are not actually a subclass and therefor cannot implement a protected method. If you however omit the method and than the compiler complaints you are missing a method.

Quick sample to illustrate:

class A { 
     protected hello() {} 
 }

class B implements A {
    // protected hello() {} 
}

One possible solution would be the compiler should ignore protected (and private) properties when implementing a class, only seeing the public properties as part of the externally exposed interface of a class.

[NoelAbrahams]

See also #471

[danquirk]

I think this is close enough to #471 to call this a duplicate, although clearly private and protected need to both be considered. This situation does feel a little awkward but #471 has some details on why a good solution isn't obvious.

[benliddicott]

Related to issue #3854 which suggests allowing implementing protected methods and properties when implementing a class interface. You can't not implement them for the reason given by @DanielRosenwasser (other "real" instances of the base class may expect to see the private methods). You also don't want to let the implementer accidentally trample on the base class state. But if they are aware of the danger and want to do it anyway, there should be a way for them to say so.