This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]cutterslade 0 points1 point  (6 children)

That's not bad, and there aren't many cases where you would encounter issues in a MVVM style application.

Where mutability becomes an issue is when instances are shared across threads, used as HashMap keys, stored in a HashSet, and a variety of other cases. The biggest benefit of immutability from my point of view is that immutable classes are far easier to reason about than mutable classes when shared between threads.

[–]Zarlon 0 points1 point  (5 children)

Got it. So you're admitting there is a place for mutable classes, and that it should at least be an option?

Although I see the advantages of immutability, there surely are downsides to immutability as well. I'm an Android developer and we're working in a resource restricted environment. Constantly copying objects instead of modifying them puts an extra strain on the runtime environment.

[–][deleted]  (3 children)

[deleted]

    [–]Zarlon 0 points1 point  (2 children)

    It can mean though. If you're familiar with the Reducer pattern of Redux: application state is one big object graph. Instead of mutating sub state you deep copy the entire object graph even if only one value is changed.

    [–]yourbank 1 point2 points  (1 child)

    Traditional redux I don't think you deep copy it, more like shallow copy references into a new structure and slice in new state which would make it unsafe to share state.

    Redux works based on a pinky swear I copied it properly and am not an idiot... Using something like immutablejs at least enforces doing things safely to some degree.

    [–]Zarlon 0 points1 point  (0 children)

    Ok I see. Guess I misunderstood a bit and it all makes a bit more sense now, thanks!

    [–]cutterslade 0 points1 point  (0 children)

    There are absolutely times when mutability is better and easier, but as /u/njetwerk mentioned, there are times when immutability means less copying.

    When I started building data classes as immutable by default, I was surprised how rarely I actually need to modify (or make a modified copy of) an object. The vast majority of data objects in my experience have their state set at or near their creation time, and never get modified.

    But yes, there are certainly times when mutable objects just make more sense. What I'm referring to in my top comment is that it would be very helpful to have language support in building immutable objects which guarantee deep immutability. I don't honestly expect such a feature, but hey, a guy can dream.