Is it possible to inherit from a data class?

# announcements

[Nir]

Is it possible to inherit from a data class?

[streetsofboston]

No. It's not an open class type and you can't define them to be open.

[Nir]

I see. Is there any discussion of making it easy to write your own data calsses such that you have say, a User and a MutableUser that inherits from User?

[Nir]

The same way that you have List and MutableList, etc, in the standard library

[Nir]

data classes look really nice, and I appreciate how much Kotlin supports immutability. However, while copy is decent, I recall from python named tuples how that approach got old pretty fast.

[Nir]

x = x.copy(age=5) is just really verbose compared to x.age=5.

[Nir]

Sometimes in a local context you just want to quickly build up a DataClass member by member, but in other places you still want to get the benefits of immutability

[gildor]

Why not just use mutable class? Even data class can be mutable

[gildor]

List and MuyableList from standard library are interfaces, you also can use this approach

[gildor]

What do you mean by "member by member"? Why not just use constructor for this?

[streetsofboston]

Side note: A data class, like a regular class, can be mutable, but you’d better better be very careful when their instances are put into a hash-list/set/collection…. 🙂

[Nir]

@gildor Sometimes it's just more convenient. Hard to say in general, without showing code.

[Nir]

The fact is that copy does exist in that form for a reason, and x = x.copy(age=5) is still very verbose

[Nir]

@streetsofboston I'm aware. It's just nice to be immutable, or mutable, depending which is suitable for the situation.

[Nir]

Standard library classes give you that, because of the inheritance relationship. So functions for example can take List, and you can call them with your MutableList, which is fantastic.

[Nir]

I'd like a relatively easy way to do that for user classes.

[Nir]

And, specifically as a starting point, data classes 🙂

[streetsofboston]

You can define an interface that your data class implements. However, the copy function won’t be derivable from that interface….

[Nir]

I'm coming from C++ where you have const as a modifier, which is really fantastic.

[streetsofboston]

The C++ const. I like that, too. I wish, though, that const were the default and another keyword like mutable would have been used instead.

[Nir]

Yeah, I don't see good options. At it's most basic level, I'd like to be able to mutate a variable locally for convenience, but still have the guarantee that it is not mutated when passed into another function.

[Nir]

Yes, certainly the default is wrong 🙂

[Nir]

C++ const is nice nonetheless because you get this feature, for free, for every single type. void foo(const string&) is guaranteed (well, almost) not to modify its input

[Nir]

And i can call it with a regular string

[Nir]

List and MutableList essentially emulates this with inheritance.

[streetsofboston]

I have to say that I’m not a big fan of MutableList being a sub-interface of List. ImmutableList and MutableList should not have a parent-child hierarchy. If I have a List, it could be implemented by a mutable list, which means I cannot assume the List i have is actual immutable..

[streetsofboston]

For nested data classes that are only at most 2 levels deep, it may not help much, but have you looked at the “lensing” facilities of the Arrow FP library?

[Nir]

I have not, but I'm not sure I want to get into that level of complexity

[Nir]

There is nothing wrong with not being able to assume that List is immutable (IMHO)

[Nir]

immutability is a property of a type, not an interface.

[Nir]

Note that C++ works the same way; you can't assume that anything taken by const& is actually immutable.

[Nir]

D supports this with immutable keyword but it's been a pretty mixed bag by most accounts

[streetsofboston]

There’s never a perfect solution! 🙂 Well, keeps our paychecks coming, I guess 😄

[Nir]

hah

[streetsofboston]

Maybe if you start with this type of construct and go from there:

interface MyData {
    val id: Int
    val name: String
}

data class MutableMyData(
    override var id: Int,
    override var name: String
): MyData

Won’t get rid of the verbosity you try to avoid, though.

[Nir]

Yeah, I guess that would do it

[Nir]

THat' snot bad

[Nir]

However, then you can't create immutable instances

[Nir]

it's only for "function argument" purposes

[Nir]

basically

[Nir]

You also don't get a copy function in the interface

[streetsofboston]

Not being able to get teh copy function is the biggest trip-up. I wish there was a data interface of some sort

[Nir]

yeah.

[Nir]

I mean personally I think there should just be some syntactic sugar to ease this pattern

[Nir]

of immutable base, mutable derived.

[Nir]

That should also work for data classes.