search

DylanSp / deep-future

A digital implementation of R. Winder's board game Deep Future.
MIT License
0 stars 0 forks source link

Decide how to handle immutability #8

Closed DylanSp closed 4 months ago

DylanSp commented 4 months ago

As of https://github.com/DylanSp/deep-future/commit/c97b9d23c8b4afcef8d5732fe6b0373ef72b0270, I'm making heavy use of Immer's Immutable type, and the Deck type used for the game logic is fully immutable. This is somewhat inconvenient, since it requires threading the new Deck value generated from each function through a lot of code. Immer doesn't really help with this, since I still have to use the non-mutating functions even inside produce(). I should decide how I want to handle it:

  1. Continue with this style, make all game logic fully immutable
  2. Bring in fp-ts and use the State monad to make the logic look smoother
  3. Only enforce immutability at the "boundaries" of the Campaign/Game types, where the rest of the app interacts with the game logic.
DylanSp commented 4 months ago

I'm going with option 3 for convenience. I'll remove all current use of the Immutable type.

DylanSp commented 4 months ago

Previous immutable style removed in https://github.com/DylanSp/deep-future/commit/b3a8f70e31dba57233cb457ce4cb2c93001696d6.