www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Using const to Enforce Design Decisions

reply 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/
Mar 25 2019
parent reply 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.
Mar 25 2019
parent reply 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.
Mar 26 2019
parent 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.
Mar 28 2019