It makes the code icky and hard to debug, and you can simply return new immutable objects for every state change.

EDIT: why not just create a new object and reassign variable to point to the new object

  • FourPacketsOfPeanuts@lemmy.world
    link
    fedilink
    arrow-up
    29
    ·
    1 day ago

    Simply put, because you often want to change the state of something without breaking all the references to it.

    Wild off the top of my head example: you’re simulating a football game. Everything is represented by objects which hold references to other objects that are relevant. The ball object is held by player object W, player object X is in collision with and holds a reference to player object Y, player Z is forming a plan to pass to player object X (and that plan object holds a reference to player object X) and so on.

    You want to be able to change the state of the ball object (its position say) without creating a new object, because that would invalidate how every other existing object relates to the ball.

    • Giooschi@lemmy.world
      link
      fedilink
      English
      arrow-up
      6
      arrow-down
      2
      ·
      1 day ago

      What you need here is not the stability in memory (i.e. of pointers, which you lose when you recreate an object) but instead just the stability of an identifier (e.g. the index into a list).

      • Kacarott@aussie.zone
        link
        fedilink
        arrow-up
        5
        ·
        13 hours ago

        This is close, but as someone already said, an index into a list just means you are mutating the list.

        Your stable “identifier” needs to be a function, ie. a reused design pattern. Compared to the list, this would be an index function which gets an element from an arbitrary list, meaning you don’t have to mutate your list anymore, you just build a new one which still works with your function.

        This is why languages which avoid mutation and side effects are always (to my knowledge) functional languages.

      • tunetardis@lemmy.ca
        link
        fedilink
        English
        arrow-up
        12
        ·
        1 day ago

        Well, but then you’re basically just pushing the mutability onto the container, since you need to be able to replace elements within it.

        It’s a good strategy at times though. Like say you’re working in a language where strings are immutable and you want a string you can change. You can wrap it in a list along the lines s=['foo'] and pass references to the list around instead. Then if you go s[0]='bar' at some point, all the references will now see ['bar'] instead.

        • Giooschi@lemmy.world
          link
          fedilink
          English
          arrow-up
          1
          ·
          10 hours ago

          Well, but then you’re basically just pushing the mutability onto the container

          That’s the point, when programming with immutable structures you always pass the mutability onto the enclosing structure.

          It’s a good strategy at times though. Like say you’re working in a language where strings are immutable and you want a string you can change. You can wrap it in a list along the lines s=['foo'] and pass references to the list around instead. Then if you go s[0]='bar' at some point, all the references will now see ['bar'] instead.

          A list is an antipattern here IMO. Just wrap it in some dedicated object (see e.g. Java’s StringBuilder).

          • tunetardis@lemmy.ca
            link
            fedilink
            English
            arrow-up
            1
            ·
            7 hours ago

            That’s the point, when programming with immutable structures you always pass the mutability onto the enclosing structure.

            I guess the point I was trying to make here was if the data type is already mutable, there is no point in sticking it in a list just so you can replace a reference with an identifier. You’re just adding an extra level of indirection. But sure yeah, if the type is inherently immutable, you have to do something.

            A list is an antipattern here IMO. Just wrap it in some dedicated object (see e.g. Java’s StringBuilder).

            Interesting. I’m not aware of anything like StringBuilder in the standard library for either Python or JavaScript. Looks like it wraps a list of characters and tries to behave as string-like as possible? You could presumably write your own class like that or download an implementation from someplace.

            I guess in most cases in my own code, where I need a mutable string is usually as part of a larger data structure which is the thing that gets passed around by reference, so it’s easy enough to replace a field within that.

            For building up a string, I would tend to use an io.StringIO in Python with file-writing calls, but those aren’t meant for sharing. What you don’t want to do is use the += operator a lot on strings. That gets expensive unless strings are mutable (like they are in say C++'s std::string).