4 ms·

>you can override a val x:Int with a val x:Int get() Could you expand on this? I don't follow what you mean. Are you talking about some form of shadowing?

EddieRingle 6y ago
They're confusing a read-only property that can be overridden with one that's made final.
usrusr 6y ago
Kotlin is playing it fast and loose with blurring the line between fields and bean-style properties. In Java you could have a public final field and it was obvious that it was immutable (unless referencing a mutable object). Kotlin, in an attempt to match Groovy in syntax cuteness, allows to declare a val (supposedly the equivalent of a java final field) that is actually not backed by memory at all but a getter method in disguise. val x: Int // this is an immutable value val y: Int // this is an immutable Function0<Int> that is executed each time and but pretends to be a val get() = System.currentTimeMillis()
- ptx 6y ago
  C# also does this, and so do Python, JavaScript and Visual Basic. Java is the odd one out by not supporting properties.
  - Too 6y ago
    Supporting properties is one thing, having assignments copy the backing property as a lazy evaluated function-pointer another, even if value is supposedly a int. Python getter properties are evaluated instantly on assignment. To convert them back into function-pointers like the Kotlin example above you really have to go out of your way by deep diving into inspect module. The result is a property-object which is not assignable to a int-variable, but type checking probably wouldn't go this deep as inspect naturally is very dynamic in its nature. My guess is Kotlin does this as a way of structural typing, if it walks like a int and talks like an int it is an int.
  - usrusr 6y ago
    Do those others heavily advertise the difference between var and val as a core feature and then sabotage it by dressing up getters (that are evaluated on each call) as immutable values?
- bobthebuilders 6y ago
  I think the main thing to understanding this is that Kotlin tries really really hard to not have fields. They're all properties, similar to get and set calls in Java (and if you have a feild in an interface it's basically that).
- Tainnor 6y ago
  I think the reason for that is that Kotlin doesn't necessarily aim for immutability as much as it aims for read-only values. This is also why there is no truly immutable implementation of `List` in the stdlib, although the interface itself it read-only (but it can still point to a value that is being mutated somewhere else). I agree that true immutability - or code that is more obvious about avoiding side-effects - could be useful, but I don't think that was ever the goal.
  - usrusr 6y ago
    That's certainly an accurate description of the cause. But I don't think that it's a valid excuse: not supporting immutability well is fine, pretending that you do when actually you don't is not. The kotlin defense to this surely is that immutability happily exists in val constructor args (with the usual exception: not transitive through references), but that's purely contextual and a difference that is very hard to represent at usage site (e.g. they look exactly the same in the intellij "javadoc" view). If for some reason bean-style methods had to be represented through var/val syntax, I think that it would have been much better if read-only calculated getters were represented by a var without set(), leaving val to cases where you're guaranteed to get the same when referenced twice (value set once in constructor or some lazyness shenanigans).

EddieRingle 6y ago

They're confusing a read-only property that can be overridden with one that's made final.

usrusr 6y ago

Kotlin is playing it fast and loose with blurring the line between fields and bean-style properties. In Java you could have a public final field and it was obvious that it was immutable (unless referencing a mutable object). Kotlin, in an attempt to match Groovy in syntax cuteness, allows to declare a val (supposedly the equivalent of a java final field) that is actually not backed by memory at all but a getter method in disguise. val x: Int // this is an immutable value val y: Int // this is an immutable Function0<Int> that is executed each time and but pretends to be a val get() = System.currentTimeMillis()

ptx 6y ago
C# also does this, and so do Python, JavaScript and Visual Basic. Java is the odd one out by not supporting properties.
- Too 6y ago
  Supporting properties is one thing, having assignments copy the backing property as a lazy evaluated function-pointer another, even if value is supposedly a int. Python getter properties are evaluated instantly on assignment. To convert them back into function-pointers like the Kotlin example above you really have to go out of your way by deep diving into inspect module. The result is a property-object which is not assignable to a int-variable, but type checking probably wouldn't go this deep as inspect naturally is very dynamic in its nature. My guess is Kotlin does this as a way of structural typing, if it walks like a int and talks like an int it is an int.
- usrusr 6y ago
  Do those others heavily advertise the difference between var and val as a core feature and then sabotage it by dressing up getters (that are evaluated on each call) as immutable values?
bobthebuilders 6y ago
I think the main thing to understanding this is that Kotlin tries really really hard to not have fields. They're all properties, similar to get and set calls in Java (and if you have a feild in an interface it's basically that).
Tainnor 6y ago
I think the reason for that is that Kotlin doesn't necessarily aim for immutability as much as it aims for read-only values. This is also why there is no truly immutable implementation of `List` in the stdlib, although the interface itself it read-only (but it can still point to a value that is being mutated somewhere else). I agree that true immutability - or code that is more obvious about avoiding side-effects - could be useful, but I don't think that was ever the goal.
- usrusr 6y ago
  That's certainly an accurate description of the cause. But I don't think that it's a valid excuse: not supporting immutability well is fine, pretending that you do when actually you don't is not. The kotlin defense to this surely is that immutability happily exists in val constructor args (with the usual exception: not transitive through references), but that's purely contextual and a difference that is very hard to represent at usage site (e.g. they look exactly the same in the intellij "javadoc" view). If for some reason bean-style methods had to be represented through var/val syntax, I think that it would have been much better if read-only calculated getters were represented by a var without set(), leaving val to cases where you're guaranteed to get the same when referenced twice (value set once in constructor or some lazyness shenanigans).