In my migration from Java to Kotlin I've a bunch o...

# announcements

[Daniele Segato]

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

Interfaces_overlapping_Java_classes_getters.kt

[gildor]

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]

You cannot override Java get/set methods with properties, there is feature request for that

[gildor]

https://youtrack.jetbrains.com/issue/KT-6653

[Daniele Segato]

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

[gildor]

This is different

[gildor]

You can use Java getter and setters as properties

[gildor]

but you cannot override methods with properties

[gildor]

So just use methods in Kotlin

[Daniele Segato]

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

[gildor]

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

[gildor]

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

[Daniele Segato]

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

[karelpeeters]

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

[gildor]

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.

[karelpeeters]

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