https://kotlinlang.org
Join Slack
Why do lateinit properties have to be var? I'd like the property to not be mutable after it's initia...
# getting-started
c
Why do lateinit properties have to be var? I'd like the property to not be mutable after it's initialized
n
well, at compile time from arbitrary methods, you can't know if it's been initialized already or not. I think that's why it's a var. but if you actually try to assign to it twice, it'll fail at runtime.
c
val
equates to 
final
, which would imply that property must be set on object creation. 
lateinit
by definition means it’s not set on object creation, but some unspecified time after that. 
lazy { }
properties are for immutable properties not set on object creation
c
Then, aside from having a "lateinit" keyword which is more explicit to the developer, what is the difference from creating a "normal" var property initialized as null at first, and later reassigning the value I desire?
I don't understand the advantage if it's var
c
But it’s probably more an artifact of the JVM roots, honestly. Without reflection, you’d get a crash trying to set a final property after creation on the JVM
The advantage is type-safety. When it’s nullable, that null carries everywhere, and as it’s var auto-casting won’t work. If you’re reasonably sure that the property will be set, 
'lateinit
allows you to forgo the null-checks as a way of telling the compiler “don’t worry, I got this one”
n
that's actually not true
lateinit vars are always null-checked when they're referenced
c
Yes, but it’s implicit. You don’t need to do 
?.
or 
!!
on it
n
it's basically 1. documentation, and 2. yeah, you don't need to specify ? or !!
c
Ok so it's because it makes the code more explicit to read and the compiler checks the "null cases" for you, understanding there "null cases" as "not yet initialized"
Is it correct?
n
yeah
depending on the use case, 
by lazy { }
might also be more appropriate, and lets you use vals
c
Okay thank you very much to both, although I still don't understand very well why I'm not allowed to say "this lateinit var, once it's initialized, won't be mutable"
I guess it has to do with some JVM dark magic you mentioned before
n
it's a little weird because it's a design concession that sometimes you need to do crap like that. like in a Spring bean's @PostConstruct method and the like.
c
It would be nice to have an inspection in IntelliJ or something on it, though. Usually it would be some code-generation or reflection magic setting those properties, it’s not something you’d typically manually write code to do.
c
Yeah, In fact I found the "problem" with Android, I would try with all my heart to not declare that kind of properties If it depended on me
Everything is harder with my background which is PHP with Laravel on top (the Spring of PHP)
And the CS degree is a bit far away in my memory, I forgot a lot about how Java works
Kotlin seems like a Java with vitamins
n
in my mind it's kind of Java + C#: the good parts
with other goodies thrown in
...and type erasure. -.-
c
Wow what is that type erasure thing? It sounds like something evil 😂 I love strong typing
n
don't get me started on how evil it is 😄
but basically generic types are completely gone at runtime. it's purely a compile-time construct.
c
Woah why would they do that? I guess because performance? I have to check that out, it's the first time I read about that
n
backwards compatibility in Java 5 😄
Sun/Oracle have long been about never breaking backwards-compat. and I dunno, maybe sometimes they make bad decisions 🤷‍♂️
c
It’s an old artifact from the early days of Java when binary size was a concern, but yeah there’s no real reason for types to still be erased nowadays. Reified generics help, but those can still be a pain
c
I'm gonna read about that because I always wondered what that "reified" thing meant in Kotlin
It seems interesting, thank you!
c
I wrote this article a while back which may help you understand it better https://dev.to/cjbrooks12/kotlin-reified-generics-explained-3mie
👏 1
c
Thank you for the article! I'm gonna read it
Btw this is a bit off topic but this kind of reified/erased type thing reminds me a lot of the law of leaky abstractions, It sounds a bit like the language should "abstract" you from these things: https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/
Old but gold
I read your article @Casey Brooks, short and it goes to the point, and very clear, thank you!
5 Views
Open in Slack
PreviousNext
Powered by

kotlinlang

A modern programming language that makes developers happier.

Powered by