If I have the following class hierarchy:
abstract class Foo<out T : Bar>() {
abstract protected val thing: T
}
class Baz : Foo<BarImpl> {
override protected val thing: T = ...
}
I get a warning on Baz::thing saying:
Redundant visibility modifier
Does that mean the compiler treats it as protected without you needing to specify that, or that it has to be public?
Kotlin interfaces are similar to abstract classes. However, interfaces cannot store state whereas abstract classes can. Meaning, interface may have property but it needs to be abstract or has to provide accessor implementations. Whereas, it's not mandatory for property of an abstract class to be abstract.
In Kotlin if you override a protected member and do not specify the visibility explicitly, the overriding member will also have protected visibility. In Java the visibility is according to the modifier and the default is still public .
A Kotlin abstract class is similar to Java abstract class which can not be instantiated. This means we cannot create objects of an abstract class. However, we can inherit subclasses from a Kotlin abstract class. A Kotlin abstract class is declared using the abstract keyword in front of class name.
In Kotlin, we cannot create an instance of an abstract class. Abstract classes can only be implemented by another class which should be abstract in nature. In order to use an abstract class, we need to create another class and inherit the abstract class.
You will receive an IDE inspection style warnings in Kotlin for things like extra semi-colons you don't need, an extra generic type parameters that can already be inferred, and more. Yours for redundant visibility modifier is along the same lines.
If you expand the inspection message you will see the full text:
This inspection reports visibility modifiers which match the default visibility of an element (public for most elements, protected for members that override a protected member).
And you can turn the inspection off within your IDE if you no longer what to see it.
A few more notes about this:
When overriding a method or member of an ancestor class you are already at the same access level as when it was declared. Saying protected
is stating the obvious (to the compiler which knows it is protected
).
You are allowed to restate the access modifier again if you want. And you can open it up more, by changing it to public
. But you cannot restrict it further, for example going to private
(because if it is private how could you override it, that idea is incompatible with override
) which becomes a compiler error.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With