Using const to Enforce Design Decisions

[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.