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

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

@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?

This is different

eh 😕 one of those things of interoperability that gets in the way

But it’s completely interoperable Just do not allow nice property syntax, but you still can use methods

Yeah, I agree it's only a problem with nice syntax 🙂 Still hope some day will have it, thanks man

It's one of the things that's missing most, I still don't really get the problem with "just" allowing it.

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.

Yeah I have read those comments a bunch of times but I haven't been able to think of a specific problem situation myself.