8 ms·
Perhaps, perhaps not. I prefer mutability. The real thing here is the definition of the Player type. It should have a mutating method that resets it's score (
by aatd86 3y ago
Perhaps, perhaps not.
I prefer mutability.
The real thing here is the definition of the Player type.
It should have a mutating method that resets it's score (a method defined on *Player).
Raw access on fields is often only ok for naive, trivial implementations. Methods are often needed anyway.
That's straightforward. Immutability doesn't make any sense here.
- fifilura 3y ago> I prefer mutability ... Examples on how to avoid the bug ... Notable is that you claim here is an opinion not an argument. That immutability is not needed is also not an argument against it. The point here is that working with immutables relieves you from some cognitive stress and repetitive work such as writing accessors and making fields private.
- aatd86 3y agoIt's not just an opinion. With mutability, it's still possible to make things immutable if properly encapsulated. If everything is immutable by default and you need mutability for some reason, good luck. The heuristic is simple too. If you need something to be mutable, you should deal with pointers. So *Player and []*Player here.
- shirogane86x 3y agoI always felt like it was kind of the other way around? Speaking from experience , most languages where immutability is the default and/or the only option can usually simulate mutability or have it as a stdlib-provided escape hatch (elixir and haskell come to mind), but most languages that are mutability-first really struggle to provide any sort of immutability that is reliable.
- aatd86 3y agoAt a datastructure level, perhaps, although functional datastructures are pretty fringe. (cf. Okasaki) In general, they can still be implemented by traditional imperative languages (obviously). At the type/variable level, it's the opposite. We see it with const. Once it's in here, it's in there.