https://kotlinlang.org logo
Join Slack
Powered by
Does kotlinx serialization work for compositions o...
# getting-started
r
Does kotlinx serialization work for compositions of objects? Say I have a @Serializable data class, who contains a Foo object, and that Foo object contains a Bar object, and so on.
Copy code
class Bar { }
class Foo {
  bar: Bar
}

@Serializable
data class Context(val a: Int, val obj: Foo) {}
Do all three of these classes need to be marked as @Serializable? (edited) or will it recursively serialize everything
p
All 3 need to be marked with the serializable annotation. And if some member field is not marked with serializable, I believe it will itself throw this error.
j
@Serializable
is necessary so the compiler plugin generates a serializer for the annotated class. Serializing a root object in a composition does serialize everything recursively, but everything in the chain needs to be serializable.
👍 1
r
@Prateek @Joffrey Okay so this approach seems cumbersome then. This is for a video game. I am implementing a way to save the current state of the game into a load file on save, like json or binary representation, and then reconstruct it back into the OOP instances when I load the game up. The easiest solution is something like Python's pickle where I can literally just have one massive 
Game
object that contains a reference to all entities and items and buildings in my game, and then just pickle / serialize that object into binary and then reconstruct it or something
but having to mark every single class in my game as @Serializable is not appealing
Game has a list of Characters and Character has an Inventory class which has a list of Item instances and so on
that is a ton of @Serializables I"ll have to do.
j
having to mark every single class in my game as @Serializable is not appealing
It's even less appealing to accidentally realize at runtime that one of the classes accidentally gets serialized, and happens to have properties of unserializable types like 
InputStream
or function types.
p
Ok, I get the idea but I dont see any other way! To make serialization work, we need to annotate them to let the system know what to serialize and what not!
j
Not all classes in your Game are part of the serializable game state, and IMO it makes total sense to explicitly mark the ones that are, so you can have compile errors in case of issues
r
Am I just missing a better solution to this type of problem? Is serializing one enormous tree of serializable objects, representing the entire "game state" at that moment, a respectable approach?
j
@Prateek it is definitely possible to use reflection-based libraries to serialize this kind of stuff without "thinking", but it's less safe in general
👍 1
r
pretty much everything in a video game needs to be serialized at some point. all the items, players, buildings, spells, quests, achievement unlcocks, etc.
and I use OOP for all of those things
j
Is serializing one enormous tree of serializable objects, representing the entire "game state" at that moment, a respectable approach?
Yes, but you most likely want to control what actually is saved as part of the Game state
> pretty much everything in a video game needs to be serialized at some point Why so? The game engine most likely shouldn't. Only data should, and that is probably just a fraction of your game
r
@Joffrey When you load up the game, your character should be in the same position in the world as you were last time. So not only do I have to @Serialize the 
Character
class, I will have to serialize the 
Vector3d
that represents 
character.position
likewise, you should have the same items
so I'll serialize 
Inventory
inside of 
Character
and 
Inventory
contains a list of all of your 
Item
instances
so I'll serialize 
Item
j
I fail to see why marking even 30 classes is a big deal, compared to what you gain in performance and safety
r
just probably the vast majority of the classes in my codebase will require this annotation
it's going to be the norm instead of the exception
j
I'm assuming you use the 
data
keywork to mark your data classes. Do you consider that a big hassle to mark all data classes with the 
data
keyword?
r
That is another thing; i don't really want every entity in my codebase to be a data class
like a Character or Item
they're just normal OOP entities
not value classes or simple data structures
j
Sorry for the confusion, I didn't mean that 
@Serializable
classes should be 
data
classes, nor the other way around. I was just mentioning 
data class
as a very close analogy to what you do with serializable classes
r
ahk. I was only using data classes in my original post because i thought that was necessary to do @Serializable out of the box
also Prateek mentioned @Serializable on fields themselves... Does that mean I will have to do
Copy code
@Serializable
class Bar { }

@Serializable
class Foo {
@Serializable
  bar: Bar
}

@Serializable
data class Context(
   val a: Int,
@Serializable
   val obj: Foo) {}
j
No no
He just meant that properties need to be of a type that is serializable
p
No, you do not need to mark on every field, what I meant was if your field is a custom class reference, then that custom class needs to be marked with annotation, sorry for the confusion.
r
and if I do @Serializable on a normal class (not 
data class
, I will have to actually implement the boilerplate/algorithm myself?
🚫 1
j
I don't think so
AFAIK the compiler plugin will generate a serializer for all properties that are actually backed by a field EDIT: yep: https://github.com/Kotlin/kotlinx.serialization/blob/master/docs/basic-serialization.md#backing-fields-are-serialized
Having to mark every serializable class with the annotation gives you the following benefits: • performance: serializers are generated at compile time, so you don't waste time at runtime to introspect the class reflectively • safety: if you use non-serializable types somewhere in your serializable hierarchy, the compiler will tell you that this is not possible. You will not try at runtime to serialize an 
InputStream
or any class that you didn't design with serialization in mind • readability: when reading the code, you can clearly see what is part of the serialized game state or not
👍 1
24 Views
Open in Slack
PreviousNext
Powered by