Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[K2] Inconsistent member representation for Java/Kotlin files #3338

Open
atyrin opened this issue Nov 13, 2023 · 4 comments
Open

[K2] Inconsistent member representation for Java/Kotlin files #3338

atyrin opened this issue Nov 13, 2023 · 4 comments
Labels
bug topic: K2 Issues / PRs that are related to the K2 migration. See #2888

Comments

@atyrin
Copy link
Contributor

atyrin commented Nov 13, 2023

Parent.java:

public class Parent {
    protected int protectedPropertyWithPublicGetterPublicSetter = 0;

    public int getProtectedPropertyWithPublicGetterPublicSetter() {
        return protectedPropertyWithPublicGetterPublicSetter;
    }

    public void setProtectedPropertyWithPublicGetterPublicSetter(int protectedPropertyWithPublicGetterPublicSetter) {
        this.protectedPropertyWithPublicGetterPublicSetter = protectedPropertyWithPublicGetterPublicSetter;
    }
}

Child.kt

open class Child: Parent()

In K1, both pages look the same:

image

In K2, the page for Java parent looks the same as in K1. But for Kotlin, inheritor getter/setter methods are omitted.
image

Representation in K2 for Kotlin files looks correct (as no getters/setters are available in the code). But it seems for the Java class, it should be the same.

Installation

  • Dokka version: 1.9.20

Parent: #3328

@atyrin atyrin added the bug label Nov 13, 2023
@IgnatBeresnev IgnatBeresnev added the topic: K2 Issues / PRs that are related to the K2 migration. See #2888 label Nov 13, 2023
@atyrin
Copy link
Contributor Author

atyrin commented Nov 14, 2023

Related: #3128

@IgnatBeresnev
Copy link
Member

IgnatBeresnev commented Dec 8, 2023

For the given code, the child's page and the parent's page should look the same, as for the K2 child's page, so like this

image

@IgnatBeresnev
Copy link
Member

Blocked by #3576

@vmishenev
Copy link
Member

The summary based on the spike #3576:
Presumably we decided to show a backing field, a getter, and a setter always.
We are going to ask to validate our decision other teams, e.g. Kotlin Evolution (as they can have plans on https://youtrack.jetbrains.com/issue/KT-6653).


We are not sure about the case with a private field:

public class A {
   private int prop = 1;
   public int getProp() {
       return prop;
   }
   public void setProp(int a) {
       this.prop = a;
   }
}

Should Dokka display accessors here?! Despite the counter-example below, It seems a field and its accessors should be an united entity.

class B : A() {
    override fun getProp(): Int {
        ....
    }
    override fun setProp(a: Int) {
        ...
    }
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug topic: K2 Issues / PRs that are related to the K2 migration. See #2888
Projects
None yet
Development

No branches or pull requests

3 participants