¿Símbolos o clases de casos para enviar mensajes a los actores de Scala?

Question

En los ejemplos de actores de Scala, he visto dónde se envía un mensaje sin parámetros a un actor (como this ), clase de caso es (o case case s) se crearon y luego se usaron como mensajes. Los símbolos funcionan igual de bien y se ven un poco más limpios y, después de leer un libro sobre Erlang, parecen más naturales. Supongo que la igualdad de símbolos funcionaría para actores remotos.

Para los mensajes con parámetros, las clases de casos serían la opción obvia, ¿por lo tanto, tal vez la coherencia entre los tipos de mensajes sea un problema?

¿Hay razones para optar por uno u otro enfoque?

Answer 1

No creo que los Symbol sean un sustituto para usar las clases de case . De hecho, no estoy completamente seguro de qué uso tiene Symbol , dado que carece de la potencia de los símbolos en otros idiomas (por ejemplo, Ruby, Smalltalk), es solo una cadena interna.

Por ejemplo, en el ejemplo de subasta estándar, es difícil ver cómo representaría la complejidad de una oferta / oferta utilizando solo símbolos.

En cuanto al caso objetos , también creo que estos son preferibles a los símbolos. Por ejemplo, pueden ser instancias de trait s, etc. y, por lo tanto, pueden proporcionar funcionalidad.

Answer 2

La respuesta corta es la verificación en tiempo de compilación.

Incluso los símbolos de pensamiento se pueden usar como mensajes y son incluso más sucintos que los objetos de casos (no es necesario definirlos), el compilador no puede detectar los símbolos mal escritos y le resultará difícil averiguar por qué los actores no están recibiendo Mensajes específicos cuando se supone que deben.

Si se usan clases de casos y / u objetos como mensajes, el compilador le dirá si está intentando enviar y / o recibir mensajes inexistentes antes de que se ejecute el programa.