scala - probabilidad - odio eterno al futbol moderno libro

¿Por qué a la gente de Scala no le gusta la anotación? (4)

El atributo en .NET es una característica muy popular. Y Java agregó Annotation después de 1.5. Las anotaciones se usan en todas partes, vea Java EE y Spring. Pero pocos scala utilizan la anotación de la biblioteca. lift-json no lo use. lift-record no lo use. Squeryl no lo usa. el subcutáneo no lo usa (tiene anotaciones para el compilador) ... Solo se mencionan unos pocos.

Usan la anotación solo cuando necesitan algo de magia de compilación. @tailrec, @inline, @BeanProperty, @Inject (en subcutáneo) ...

Scala tiene un sistema de tipo súper flexible, un rasgo, implícito y Menifest [X]. ¿Entonces no necesitan metadatos en tiempo de ejecución?

¿Hay alguna anotación de uso del proyecto scala en gran medida?

ps creo que la Dynamic debe ser una anotación pero no un rasgo.

Casi has respondido tu propia pregunta cuando dijiste que se usan para la compilación mágica. Para los otros usos, generalmente se trata de algún tipo de magia en tiempo de ejecución, donde las dos herramientas principales son la reflexión y la transformación del código de bytes.

Para el caso JSON, las opciones para la conversión serían las siguientes: 1. Una función o clase que analiza su JValue y construye su clase T. 2. Reflexión sobre las clases objetivo para determinar su diseño y lo que es opcional, luego " código "dinámico" que se ejecuta sobre los datos analizados para crearlos y, finalmente, convertirlos al tipo apropiado.

En general, no utilizamos anotaciones porque no las necesitamos para muchas cosas.

Los pocos lugares donde he visto las anotaciones usadas:

Sistemas de tipo extra (por ejemplo, el complemento CPS para continuaciones delimitadas o el complemento de seguimiento de efectos).
Interfaz con interfaces Java heredadas. ( scala-mojo-support )
Hacer cumplir / habilitar las optimizaciones del compilador, como @inline o @tailrec .

En Scala, realmente no necesitamos un marco de inyección de dependencia, ya que hay algunas maneras de realizar la inyección de dependencia que no requiere una herramienta externa. Puede tener la configuración de DI separada del código del núcleo, pero aún puede escribirse en Scala. Consulte: https://github.com/jsuereth/scala-in-depth-source/blob/master/chapter11/src/main/scala/scalax/config/Test.scala

Entonces, la respuesta básica es que no hay nada de malo en las anotaciones, simplemente no las necesitamos con tanta frecuencia (todavía).

Para mí, a menudo es un problema de seguridad de tipo de compilador. Eche un vistazo a Squeryl y en qué se diferencia de un ORM de Java como Hibernate. Donde Hibernate usaría una anotación @Id para denotar una clave primaria, en Squeryl creas un miembro id, que está especificado por el rasgo KeyedEntity. Los métodos que requieren una entidad con una clave principal (actualización y eliminación, por ejemplo) se bloquearán con fuerza en el momento de la compilación si no se ha definido uno. Hay varios otros lugares dentro de Squeryl donde las construcciones seguras para los tipos reemplazan las anotaciones como el mapeo de colecciones y el manejo de fecha / hora.

Creo que esta es una forma común de pensar en la comunidad Scala. Las anotaciones son más bien una función de tiempo de ejecución y no son tan bien consideradas. El compilador de Scala es muy poderoso y empujar más de su código en construcciones que puede validar tiene sentido para aquellos que están dispuestos a aceptar la complejidad que viene con eso.

Todas las anotaciones como @tailrec y @inline son solo de compilación. Extienden StaticAnnotation, que es, AFAIK, el único soporte de anotación en Scala, y no se conservarán en tiempo de ejecución. Creo que la filosofía es evitar las anotaciones en tiempo de ejecución porque éstas se recuperan a través de la reflexión, un mundo donde el compilador ya no puede ayudarlo más allá de las clases estándar debido a la eliminación de tipos, pero lo más importante, porque es el tiempo de ejecución y el objetivo es decidir lo que quiere Estoy tratando de decidir en tiempo de compilación.

Considere el uso de anotaciones para modelar una salida JSON, por ejemplo: en Java sabría si funciona bien cuando ejecuta su programa. En Scala puede usar clases de tipo para modelar cómo se expresa cada tipo en JSON. Si te olvidas de una definición, la compilación te lo dirá. Un excelente ejemplo es spray-json .

Dave Whittaker da otro gran ejemplo en su answer .