Why do you have to pass overrided properties as ar...

# language-evolution

[Sam Stone]

Why do you have to pass overrided properties as arguments when subclassing?

open class Parent(open val x: Int)
class Child(override val x: Int): Parent(x)

Instead of

open class Parent(open val x: Int)
class Child(override val x: Int): Parent()

[Wesley Hartford]

In most cases, I think you'd be better off not overriding:

open class Parent(open val x: Int)
class Child(x: Int): Parent(x)

[Wesley Hartford]

In general, you have to pass the parameter to the constructor because it's part of the Parent's constructor. An alternative change to the code would be to make the x a (possibly abstract) member of parent, but not put it in the constructor.

[ephemient]

open class Parent(open val x: Int)
class Child(override val x: Int) : Parent(x = x + 1)

is legal (and confusing)

[ephemient]

IMO this pattern with shadowing concrete properties is bad

[ephemient]

if you wrote

open class Parent {
    abstract val x: Int
}
class Child(override val x: Int) : Parent()

then there is no ambiguity and no duplication

[Klitos Kyriacou]

It makes sense if you think about the equivalent Java class:

class Parent {
    private int x;
    public int getX() { return x; }
    public Parent(int x) { this.x = x; }
}

For which you now need:

class Child extends Parent {
    Child(int x) {
        super(x);
    }

    // You don't need the below, therefore you don't need class Child(override val x: Int)
    private int x;
    public int getX() { return x; }
}

Or, of course, you can use Ephemient's suggestion, equivalent to:

class Parent {
    abstract int getX();
}

[ephemient]

what OP wrote originally would translate into Java like

class Parent {
    private int x;
    public int getX() { return x; }
    public Parent(int x) { this.x = x; }
}
class Child extends Parent {
    private int x;
    @Override
    public int getX() { return x; }
    public Child(int x) { super(x); }
}

where there are two different fields x which are not necessarily in sync with each other

[ephemient]

either of the alternatives is better than that

[Sam Stone]

Can't there be a better way to inherit a constructor with the addition of a single property? Consider the following scenarios:

open class Parent<T>(val value: T)
class Child(override val value: Int): Parent(value)

Or

open class Parent(val value: Int)
class Child(val value1: Int, val value2: Double): Parent(value1)

It would be nice if there was a simple way to specify the type of T (e.g. class Child(_): Parent<Int>(_) - and Child(1F) would be a type error), or add an additional property (e.g. class Child(_, val value2: Double): Parent(_)) and avoid the need to repeat constructors.

[ephemient]

same deal as above. don't do that. pick one of

open class Parent<T> {
    abstract val value: T
}
class Child(override val value: Int) : Parent<Int>()

open class Parent<T>(val value: T)
class Child(value: Int) : Parent<Int>(value)

[ephemient]

you're going to have to write Int at least twice either way but that is for different reasons (https://youtrack.jetbrains.com/issue/KT-43594)

[Sam Stone]

Except the compiler requires writing the code in my original post if I want to make Child a data class and only have a primary constructor and name the property the same as in the parent class, because I need to add val/var. Hence, none of the suggested solutions will work (unless I want to declare abstract properties in the parent class, which is not ideal).

[ephemient]

what is not ideal about abstract properties? the tradeoffs are better than a non-abstract parent with open concrete properties

[David Kubecka]

Is any of the last two variants (abstract property or constructor argument) generally preferred? Or can you at least imagine concrete situations where one is more suitable than the other?