Writing it by hand or generated by compiler is an ...
# announcements
e
Writing it by hand or generated by compiler is an other question though
d
It doesn't matter if you write
Copy code
interface GetText {
    fun getText(): String
}

class MyClass(@JvmField val _text) : GetText {
    override fun getText() = _text
}
or
Copy code
interface GetText {
    val text: String
}
class MyClass(override val text: String) : GetText
The resulting bytecode is identical.
e
Ya I know they will be the same, but the original question wasn't asked by me
d
I know.
e
Using
@JvmField
is just a fast way to get rid of that warning IMO
d
It's the wrong way though... 😄
e
I think what's wrong is the use of the
GetText
interface
d
How so?
e
That enum class already got a
val text
, the compiler will give you the
getText()
Why bother adding a interface for the
getText()
?
d
One example: You have different enum types that both implement
GetText
.
e
Unless he wants to do additional thing inside
getText()
d
This is the whole point of interfaces.
e
True..but in this case he just accidentally use a property name that matches the function
in other cases, this will works fine
d
No, I assume he did not realize he can put properties in interfaces (probably Java background). So he tried to write a getter and assumed
val
is like a field in Java.
He has more than one enum class, he talked about that earlier.
e
Oh I think that's the root cause then
m
Yes, I didn’t know that you can put vals in interfaces and yes, I want to use multiple enums that all implement the interfaces. The problem is solved (val in interface).