https://kotlinlang.org logo
#getting-started
Title
# getting-started
c

Carrascado

08/05/2020, 5:06 PM
Why do lateinit properties have to be var? I'd like the property to not be mutable after it's initialized
n

nanodeath

08/05/2020, 5:10 PM
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

Casey Brooks

08/05/2020, 5:10 PM
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

Carrascado

08/05/2020, 5:12 PM
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

Casey Brooks

08/05/2020, 5:12 PM
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

nanodeath

08/05/2020, 5:14 PM
that's actually not true
lateinit vars are always null-checked when they're referenced
c

Casey Brooks

08/05/2020, 5:14 PM
Yes, but it’s implicit. You don’t need to do
?.
or
!!
on it
n

nanodeath

08/05/2020, 5:14 PM
it's basically 1. documentation, and 2. yeah, you don't need to specify ? or !!
c

Carrascado

08/05/2020, 5:17 PM
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

nanodeath

08/05/2020, 5:18 PM
yeah
depending on the use case,
by lazy { }
might also be more appropriate, and lets you use vals
c

Carrascado

08/05/2020, 5:19 PM
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

nanodeath

08/05/2020, 5:22 PM
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

Casey Brooks

08/05/2020, 5:23 PM
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

Carrascado

08/05/2020, 5:24 PM
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

nanodeath

08/05/2020, 5:27 PM
in my mind it's kind of Java + C#: the good parts
with other goodies thrown in
...and type erasure. -.-
c

Carrascado

08/05/2020, 5:29 PM
Wow what is that type erasure thing? It sounds like something evil 😂 I love strong typing
n

nanodeath

08/05/2020, 5:33 PM
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

Carrascado

08/05/2020, 5:35 PM
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

nanodeath

08/05/2020, 5:38 PM
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

Casey Brooks

08/05/2020, 5:39 PM
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

Carrascado

08/05/2020, 5:44 PM
I'm gonna read about that because I always wondered what that "reified" thing meant in Kotlin
It seems interesting, thank you!
c

Casey Brooks

08/05/2020, 5:46 PM
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

Carrascado

08/05/2020, 5:47 PM
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!
3 Views