3

私はビッグバン スタイルのプログラミングを使用してゲームに取り組んでおり、状態全体を単一のデータ構造として定義し、単一のアトムに対してスワップすることで状態の変化を管理しています。

ゲームでは、クライアントから送信されたデータを信頼できないため、サーバーはいくつかの動きが無効になる可能性を予測して、それを防ぐ必要があります。世界の状態を交換するための関数を書くとき、純粋な状態から始めることができます。ただし、無効なリクエストの可能性を考慮する必要があります。私は、慣用的な Clojure の不幸な道に影響を与えるのは、単純に例外をスローすることだと信じています。そのため、純粋だった可能性のある関数が副作用の例外に感染しています。おそらく、これはあるべき姿です。

(try
  (swap! world update-game) ;possible exception here!
  (catch Exception e
    (>! err-chan e))

私の目標は、可能な限り最後の瞬間まで副作用を延期することです. 私は Haskell の世界に足を踏み入れたことはほとんどありませんが、Either モナドの概念は知っています。幸福な道と不幸な道を考えると、常にこの 2 つの可能性があることがわかります。swap!不幸な道を無視しているので、これだけでは不十分だと思います。アイデアの精神は次のとおりです。

(swap-either! err-chan world update-game) ;update-game returns either monad

Clojure コミュニティは、例外を処理するためのより機能的なアプローチを採用しましたか?

4

1 に答える 1