• Mike Parker (7/7) Mar 25 2019 Marco de Wild has penned a tutorial on D's const for the D blog.
• Rubn (5/12) Mar 25 2019 I guess obligatory
• Marco de Wild (28/32) Mar 26 2019 Good to read a different take on the subject. Jonathan uses a lot
• Walter Bright (5/8) Mar 28 2019 Using pure is indeed hard. One has to make a change in how one thinks ab...

Mike Parker <aldacron gmail.com> writes:

Marco de Wild has penned a tutorial on D's const for the D blog. 
He gives an overview of the feature, how it differs from C++, and 
shows how he employed it in his mahjong game.

The blog:
https://dlang.org/blog/2019/03/25/using-const-to-enforce-design-decisions/

Reddit:
https://www.reddit.com/r/programming/comments/b5a9jm/using_const_in_d_to_enforce_design_decisions/

Rubn <where is.this> writes:

On Monday, 25 March 2019 at 13:00:07 UTC, Mike Parker wrote:
 Marco de Wild has penned a tutorial on D's const for the D 
 blog. He gives an overview of the feature, how it differs from 
 C++, and shows how he employed it in his mahjong game.

 The blog:
 https://dlang.org/blog/2019/03/25/using-const-to-enforce-design-decisions/

 Reddit:
 https://www.reddit.com/r/programming/comments/b5a9jm/using_const_in_d_to_enforce_design_decisions/

I guess obligatory 
http://jmdavisprog.com/articles/why-const-sucks.html

Would be nice to see the source code for this mahjong game as 
well.

Marco de Wild <mdwild sogyo.nl> writes:

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.

Walter Bright <newshound2 digitalmars.com> writes:

On 3/26/2019 12:57 AM, Marco de Wild wrote:
 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.

Using pure is indeed hard. One has to make a change in how one thinks about 
programming to make good use of it, it can't just be schlepped on. But the 
results can be pretty cool.

Same with const.