Using const to Enforce Design Decisions
Marco de Wild
mdwild at sogyo.nl
Tue Mar 26 07:57:07 UTC 2019
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.
More information about the Digitalmars-d-announce
mailing list