| |
| Posted by Marco de Wild in reply to Rubn | PermalinkReply |
|
Marco de Wild
| 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.
|