Hey folks, I'm looking into data classes and I wanted to verify that `copy` creates shallow, not dee...

# server

[julien lengrand-lambert]

Hey folks, I'm looking into data classes and I wanted to verify that copy creates shallow, not deep copies. The math checks out for complex types such as lists or other data classes, but not for 'primitives' likes Strings and Enums. Can someone help me clarify this? [Here is a complete example](https://pl.kotl.in/CzsYyKC_l) , but in essence for the given code, I would potentially expect name to also be mutated in the copy if data classes were purely shallow.
Am I getting this wrong?

import java.util.*

enum class WEAPONS{
    AXE, SWORD, WAND, BOW
}

enum class CLASS{
    WIZARD, WARRIOR, PALADIN, THIEF
}

data class Origin(val city: String, var country: String)

data class FantasyHero(var name: String, val weapons: MutableList<WEAPONS>, var heroClass: CLASS?, val origin: Origin = Origin("Utrecht", "The Netherlands"))

fun main(){
    val gandalf = FantasyHero("Gandalf the Grey", mutableListOf(WEAPONS.WAND), CLASS.WIZARD)
    val anotherGandalf = FantasyHero("Gandalf the Grey", mutableListOf(WEAPONS.WAND), CLASS.WIZARD)
    val gandalfCopy = gandalf.copy()
    val betterGandalf = gandalf.copy(name="Gandalf the White")

    println("--------")
    println("Changing the first instance's name")


    gandalf.name = "Gandalf the White"
    println(gandalf.name)
    println(anotherGandalf.name)
    println(gandalfCopy.name)
    println(betterGandalf.name)

    println("--------")
    println("Changing the first instance's class")

    gandalf.heroClass = CLASS.PALADIN
    println(gandalf.heroClass)
    println(anotherGandalf.heroClass)
    println(gandalfCopy.heroClass)
    println(betterGandalf.heroClass)
}

--------
Changing the first instance's name
Gandalf the White
Gandalf the Grey
Gandalf the Grey
Gandalf the White
--------
Changing the first instance's class
PALADIN
WIZARD
WIZARD
WIZARD

[Sam]

This is quite a long example; is there a specific line or part of the example that’s behaving in a way you don’t expect?

[Sam]

Your understanding that copy creates shallow copies is correct

[Larry Meadors]

i think this is a terminology issue

[julien lengrand-lambert]

@Sam, much shorter example ->

data class Origin(var city: String, var country: String)


fun main(){
    val myHome = Origin("Utrecht",  "the Netherlands")
    val myHomeCopy = myHome.copy()
    
    myHome.city = "Amsterdam"
    println(myHome.city)
    println(myHomeCopy.city)

}

[julien lengrand-lambert]

If we are talking about pure shallow copies, I'd expect myHome.city and myHomeCopy.city to print the same value here (since they reference the same location in memory, right?)

[Larry Meadors]

i'd expect to see:

Utrecht
Amsterdam

[julien lengrand-lambert]

Except I get Amsterdam, UTrecht

[Sam]

The Kotlin/Java memory model is a bit different from what you’re picturing, I think

[julien lengrand-lambert]

Now, for anything more complex (Lists, other data class, Set, ...), The values do get mutated in the copies as well

[Sam]

Think of it more like a pointer

[Larry Meadors]

copy creates a new instance with the same top-level (shallow) values

[Larry Meadors]

the "values" for a list or set are the references to them

[julien lengrand-lambert]

So, if we do think of it as pointers indeed, how is it that I don't get "Amsterdam, Amsterdam"? I would expect both String pointers to point to the same value ?

[Sam]

References in Kotlin are immutable — if you change a variable you’re pointing it at a new reference, not changing the existing reference

[Larry Meadors]

not a pointer to the copied object, but a pointer to the property

[Larry Meadors]

(sam i saying this better than me 🙂)

[Sam]

var a = "1"
val b = a
a = "2"
println(b) // "1"

same concept, without the data class copy being involved

[Sam]

the reference is always immutable; all you can do is point at a different object reference instead

[Sam]

Nothing you do to a can change which object b points to

[julien lengrand-lambert]

🧐

[julien lengrand-lambert]

Right

[julien lengrand-lambert]

Yeah I think I got it. The behaviour will be the same for anything that you can set like this. So enums have the same behaviour

[julien lengrand-lambert]

Got it, ty

[Sam]

It catches out a a lot of newcomers to Java tbh, I think people who started out on Java don’t always realise how different it is from other languages

[Sam]

People often ask “is Java pass by reference or pass by value”

[Sam]

And the answer is actually “it’s pass by value but the value is a reference” 😂 🤦

[julien lengrand-lambert]

oh well, I only have 10 years of experience xD

[julien lengrand-lambert]

Thanks! Good to come back to the basics sometimes clearly

[Larry Meadors]

@Sam you are only the second java dev i have heard say that (i am the other one) 😄

[Larry Meadors]

“it’s pass by value but the value is a reference” - always always always pass by value 😄

[cedric]

Unrelated to your question, @julien lengrand-lambert, but your code has a lot of var and mutable list that don't seem necessary.

[julien lengrand-lambert]

Thanks @cedric. you're very correct, it's actually the point. I typically use only vals but use vars explicitely to mutate things around and see the behaviour of those 😊

[cedric]

While I think that val and immutable structures are a great default starting point, writing a lot of Rust these past years has made me more comfortable embracing the mutable nature of things as long as the compiler makes sure I'm not writing stupid code 🙂

[cedric]

In much the same way that Kotlin has made me more comfortable embracing null values