https://kotlinlang.org logo
#announcements
Title
# announcements
n

Nir

07/05/2019, 2:34 PM
Is it possible to inherit from a data class?
s

streetsofboston

07/05/2019, 2:37 PM
No. It's not an open class type and you can't define them to be
open
.
n

Nir

07/05/2019, 2:39 PM
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?
The same way that you have List and MutableList, etc, in the standard library
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.
x = x.copy(age=5)
is just really verbose compared to
x.age=5
.
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
g

gildor

07/05/2019, 3:10 PM
Why not just use mutable class? Even data class can be mutable
List and MuyableList from standard library are interfaces, you also can use this approach
What do you mean by "member by member"? Why not just use constructor for this?
s

streetsofboston

07/05/2019, 3:14 PM
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…. 🙂
n

Nir

07/05/2019, 3:18 PM
@gildor Sometimes it's just more convenient. Hard to say in general, without showing code.
The fact is that copy does exist in that form for a reason, and
x = x.copy(age=5)
is still very verbose
@streetsofboston I'm aware. It's just nice to be immutable, or mutable, depending which is suitable for the situation.
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.
I'd like a relatively easy way to do that for user classes.
And, specifically as a starting point, data classes 🙂
s

streetsofboston

07/05/2019, 3:20 PM
You can define an interface that your
data class
implements. However, the
copy
function won’t be derivable from that interface….
n

Nir

07/05/2019, 3:20 PM
I'm coming from C++ where you have
const
as a modifier, which is really fantastic.
s

streetsofboston

07/05/2019, 3:21 PM
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.
n

Nir

07/05/2019, 3:21 PM
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.
Yes, certainly the default is wrong 🙂
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
And i can call it with a regular
string
List
and
MutableList
essentially emulates this with inheritance.
s

streetsofboston

07/05/2019, 3:24 PM
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..
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?
n

Nir

07/05/2019, 3:29 PM
I have not, but I'm not sure I want to get into that level of complexity
There is nothing wrong with not being able to assume that
List
is immutable (IMHO)
immutability is a property of a type, not an interface.
Note that C++ works the same way; you can't assume that anything taken by
const&
is actually immutable.
D supports this with
immutable
keyword but it's been a pretty mixed bag by most accounts
s

streetsofboston

07/05/2019, 3:31 PM
There’s never a perfect solution! 🙂 Well, keeps our paychecks coming, I guess 😄
n

Nir

07/05/2019, 3:33 PM
hah
s

streetsofboston

07/05/2019, 3:50 PM
Maybe if you start with this type of construct and go from there:
Copy code
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.
n

Nir

07/05/2019, 4:00 PM
Yeah, I guess that would do it
THat' snot bad
However, then you can't create immutable instances
it's only for "function argument" purposes
basically
You also don't get a copy function in the interface
s

streetsofboston

07/05/2019, 4:03 PM
Not being able to get teh
copy
function is the biggest trip-up. I wish there was a
data interface
of some sort
n

Nir

07/05/2019, 4:03 PM
yeah.
I mean personally I think there should just be some syntactic sugar to ease this pattern
of immutable base, mutable derived.
That should also work for data classes.
👌 1
5 Views