https://kotlinlang.org logo
Join Slack
Powered by
<https://twitter.com/kotlin/status/122799350533268...
# announcements
u
https://twitter.com/kotlin/status/1227993505332682753 Did you know? Properties declared as 'val' can be overridden as 'var', and property setters can be made less visible than their getters #KotlinTips https://t.co/Ba1LxBF4dI https://t.co/U4Dpqo1Mlz https://t.co/dHP8O6YHOI Twitter
😲 3
f
That's why parent classes should never make their properties open if they require them to be immutable but request them through their constructor. Personally not surprised it's totally logical but I can see how this might seem wrong to many and maybe even unexpected.
👍 2
a
Oh I see, now is when people says it's not a bug it's a feature, right? 😂
s
Look at it from a getter/setter point of view. For a method declared in a base class, a subclass can increase/widen its scope/visibility. Overriding a val by a var is like overriding a lesser visible setter into a public one.
f
Not quite, no. Have a look at the Java equivalent and it all starts to make sense.
s
Ah, it just adds a setter. ❄️
f
Java fix and you fix it the same way in Kotlin (with much less code). There is not much Kotlin can do about this if they want to keep Java compatibility. This is what happens if you build a language on top of another one (this sounds very negative towards Kotlin but it's not meant like this, it's just an objective assertion of the situation).
m
Pedantic point. Kotlin is not built on top of Java. It compiles to JVM bytecode. This is allowed in JVM bytecode but they could have the Kotlin compiler prevent it. They chose not to as there are legit use cases. It's just not intuitive in Kotlin because of the inherent meaning to things like 
val
and 
var
.
f
I think you misunderstand: changing the semantics here would not allow Java classes to normally interact with their parent class if that one is defined in Kotlin. However, this kind of compatibility is a major selling point of Kotlin.
Open in Slack
PreviousNext
Powered by