`data classes` are not allowed to have non-propert...

# announcements

[thana]

data classes are not allowed to have non-properties in their primary constructors. otoh this means data classes cannot inherit from classes that require arguments in their own primary constructor. is there a way to overcome this issue? is this really intended? why?

[gildor]

data classes cannot inherit from classes that require arguments in their own primary constructorv

No, it’s of course possible, do you have some sample where it doesn’t work for you?

[gildor]

https://pl.kotl.in/xyDp1eBuL

[Pavlo Liapota]

I guess he means:

data class Bar(a: String) : Foo(a)
open class Foo(val a: String)

And as I know this is not allowed because all methods for a data class are generated based on properties in a constructor.

[thana]

oh, yes, sorry, i want precise enough: the point is: they always have to redecalre those fields if they want to inherit

[thana]

which OTOH causes problems e.g. with serialization AND might lead to boilerplate again

[gildor]

@Pavlo Liapota What is the point to do not expose a in data class? If you just want to override it, no problem with it, but it must be open:

data class Bar(overrider val a: String) : Foo(a)
open class Foo(open val a: String)

[Pavlo Liapota]

@gildor I agree

[gildor]

they always have to redecalre those fields if they want to inherit

Isn’t it make sense? constructor argument is not always property

[thana]

wouldn't it be cool if the copmpiler could just recognize that i do only override it and don't redeclare it? 🤔
Regarding to kotlinx.serialization it is a redeclaration as i have to makr the property in the base class @transient to avoid serialization errors

[gildor]

how would it recognize it?

[gildor]

because of the same name?

[thana]

yeah it might need a new modifier for that 😄

[gildor]

or just override explicitly

[gildor]

using existing override modifier

[gildor]

If you have proposed syntax, you can discuss it in #language-proposals

[thana]

thank you - chances are, we are just using data classes not the way, they are intended to be used 😄

[thana]

oh an as long as serialization is the only problem it causes, there is no need to change the language, i think

[gildor]

What is your use case for this?

[thana]

we have an abstract DomainEvent class which declares a key to identifiy the event. Then we have several concrete domain events which all inherit from DomainEvent

[gildor]

Maybe you just need some interface to avoid inheritance of abstract class?

[gildor]

or at least make key abstract

[thana]

yes we needed to make it abstract. but it kind of spoiles the interface of the inheriting classes. also the DomainEvent has other properties that are more or less of technical nature and nothing the implementations really should expose

[gildor]

Okay, let’s talk from another point than, why do you need data class for this?

[thana]

it feels like events are data classes

[thana]

they are immutable and should be comparable with each other based on their whole value

[gildor]

but standard class is also can be immutable

[gildor]

yeah, comparison make sense

[gildor]

serialization is problem of course, but not something unique for Kotlin or data classes

[thana]

maybe wee need a different shortcut to auto generate wquals/hashcode and tostring 🤔

[thana]

like lombok does 🤦‍♂️