https://kotlinlang.org logo
Title
d

Daniele Segato

09/04/2018, 9:37 AM
In my migration from Java to Kotlin I've a bunch of interfaces that re-define methods of the Framework for various reasons... The class
View
is part of the Android framework and has methods like:
public int getPaddingLeft() { ... }
my Java interface was:
interface MyInterface {
    int getPaddingLeft();
}
And for my widget in java I just had to implement the interface without doing anything else, the methods were already there. With Kotlin tough, the interface become a
val
declaration and the compiler complains I should implement those `val`s. If I do I get the error:
Accidental override: The following declarations have the same JVM signature (getPaddingRight()I): 
*  public open fun <get-paddingRight>(): Int defined in my.package.MyWidget
*  public open fun getPaddingRight(): Int defined in my.package.MyWidget"
the error happens on the
get()
The second one is of course the Platform method. Is there a way to tell Kotlin those are the same thing and I do not need to override anything? see kotlin code
g

gildor

09/04/2018, 9:40 AM
getPaddingRight is method of View, so you have name conflict of interace property and View getter So if you havve the same name, just use method instead of val:
val paddingRight: Int
becomes
fun getPaddingRight(): Int
You cannot override Java get/set methods with properties, there is feature request for that
d

Daniele Segato

09/04/2018, 9:42 AM
@gildor I know that's the issue, but from the class MyWidget I can use just
paddingRight
as if it was a val/var. From whoever use my Interface instead i am then forced to use the
getPaddingRight()
method instead. Isn't there a way to instruct Kotlin that those methods are actually the val?
g

gildor

09/04/2018, 9:43 AM
This is different
You can use Java getter and setters as properties
but you cannot override methods with properties
So just use methods in Kotlin
d

Daniele Segato

09/04/2018, 9:51 AM
eh 😕 one of those things of interoperability that gets in the way
g

gildor

09/04/2018, 9:51 AM
But it’s completely interoperable Just do not allow nice property syntax, but you still can use methods
Overriding methods with properties has some deep problems, you can check thread of issue that I shared with you I also hope that it will be available some day, but to be honest, not a big thing, because you can use methods instead
d

Daniele Segato

09/04/2018, 9:57 AM
Yeah, I agree it's only a problem with nice syntax 🙂 Still hope some day will have it, thanks man
k

karelpeeters

09/04/2018, 10:07 AM
It's one of the things that's missing most, I still don't really get the problem with "just" allowing it.
g

gildor

09/04/2018, 10:12 AM
according to comment from Andrey Breslav this can be backward incompatible change in some cases and also:
some mitigations strategies like the one you propose are possible. We’ll probably look into them at some point. I’m not prepared to describe all the possible risks, but I’m sure there are quite a few things to be checked before we can say it doesn’t break anything.
k

karelpeeters

09/04/2018, 10:14 AM
Yeah I have read those comments a bunch of times but I haven't been able to think of a specific problem situation myself.