On Monday, 25 March 2019 at 20:59:41 UTC, Rubn wrote:
I guess obligatory
http://jmdavisprog.com/articles/why-const-sucks.html
Good to read a different take on the subject. Jonathan uses a lot
of arguments that I recognize (and adds a few that I didn't
encounter in my project). I am a firm believer of using the type
system and the compiler to aid development. Personally, I found
it supplemental to the way I write code (with a strong DDD
influence).
I've also tried to use pure, but (ironically) I found it harder
to use. I think it's easier to understand when an object will be
mutated or not than to predict whether there are side effects.
Would be nice to see the source code for this mahjong game as
well.
https://github.com/Zevenberge/Mahjong
I've been learning on the job, so there are a few quirks of
earlier times that managed to avoid the blade of refactoring
(including a case I discovered yesterday where mutable state
could potentially leak). In general, I'm quite happy with it
though.
The code for the example in the blog is, among others:
https://github.com/Zevenberge/Mahjong/blob/master/source/engine/flow/turn.d
We are looking at a part of the state machine modelling the
various moments (phases) in a mahjong turn, more precisely the
action decided by the turn player (e.g. discard or declare a
win). A message is sent to the players (UI or AI). The message
exposes a read-only view on all game data relevant for making a
decision. Manipulations can only be done through predefined
methods in the message (conceptually a return message). This
means that the turn player can declare a win through a method in
the message, but not restart the game, as that would require
access to a mutable game object.
