Scala アクターの例では、パラメーターなしのメッセージがアクター ( thisなど) に送信される場所を確認しましたcase class。es (またはcase objects) が作成され、メッセージとして使用されます。シンボルも同じように機能し、少しきれいに見えます。Erlang に関する本を読んだ後では、より自然に見えます。リモート アクターに対しては、シンボルの等価性が機能すると思います。
パラメーターを持つメッセージの場合、ケース クラスが当然の選択になるため、メッセージ タイプ間の一貫性が 1 つの問題になるのではないでしょうか?
いずれかのアプローチを採用する理由はありますか?
簡単な答えは、コンパイル時のチェックです。
シンボルはメッセージとして使用でき、ケース オブジェクトよりもさらに簡潔 (定義する必要はありません) であっても、コンパイラはスペル ミスのシンボルを検出できず、アクターが特定のメッセージを受信しない理由を理解するのに苦労します。彼らはそうするはずです。
ケースクラスおよび/またはオブジェクトがメッセージとして使用されている場合、コンパイラは、プログラムが実行される前に、存在しないメッセージを送信および/または受信しようとしているかどうかを通知します。
s がクラスSymbolを使用する代わりになるとは思いません。case実際、他の言語 (Ruby、Smalltalk など) ではシンボルの力が不足しているため、どのような用途があるのかまったくわかりませんSymbol。これは単にインターンされた文字列です。
たとえば、標準的なオークションの例では、シンボルだけを使用してビッド/オファーの複雑さをどのように表現するかを理解するのは困難です。
case オブジェクトに関しては、これらはシンボルよりも好ましいと思います。たとえば、それらはtraits などのインスタンスである可能性があり、したがって機能を提供します。