Rasgos vs. Paquetes en Scala

Question

Después de ver Martin's keynote on Reflection and Compilers parece que no puedo sacarme esta loca pregunta de la cabeza. Martin habla, entre otras cosas, sobre el "patrón de pastel" (boda), donde los rasgos juegan el papel central. Me pregunto, ¿por qué en el mundo necesitamos paquetes cuando ya tenemos rasgos? ¿Hay algo que pueda hacer un package, qué trait (al menos teóricamente) no puede?

No estoy hablando de la implementación actual, solo estoy tratando de imaginar cómo sería la programación si reemplazamos paquetes con rasgos. En mi cabeza sería así:

• una palabra clave menos (package es innecesaria)
• sin necesidad de package object s

Para resumir todas mis preguntas:

1. Es es teóricamente posible eliminar paquetes del lenguaje y usar rasgos en su lugar.
2. ¿Qué otros beneficios obtendríamos de este cambio? (Estaba pensando en paquetes de primera clase e importaciones de primera clase, pero la composición mixin es una tarea de tiempo de compilación, aunque las supercarreteras están vinculadas dinámicamente)
3. ¿Es la compatibilidad Java/JVM lo único que se interpondría en el camino?

Actualizar

conversaciones Daniel SPIEWAK en this keynote acerca de la inyección de dependencia es sólo la punta del iceberg de todas las cosas que puede hacer con el patrón de la torta.

Answer 1

Martin Odersky ha dicho que Scala podría vivir con solo rasgos, objetos, métodos y caminos (espero no haber olvidado algo).

Ambas clases y paquetes sólo están ahí porque Scala pretende ser un lenguaje organizado, es decir, un lenguaje que se ejecuta en (esto no es en realidad la parte interesante) y interactúa con (este es el punto importante) un anfitrión plataforma. Algunas de las plataformas de host con las que pretende interoperar Scala son la plataforma Java y la CLI, ambas tienen un concepto de clases y paquetes (espacios de nombres en el caso de la CLI) que es lo suficientemente distinto como para que no se pueda expresar fácilmente como rasgos u objetos. Esto es diferente de las interfaces, que pueden mapearse trivialmente desde y hacia rasgos puramente abstractos.

La afirmación anterior se realizó en una discusión sobre la posible eliminación de genéricos de Scala, porque todo lo que los genéricos pueden hacer también se puede lograr mediante tipos abstractos.

Answer 2

En scala, el objeto y el paquete tienen casi el mismo propósito y los objetos también se llaman módulos. Los objetos merecen ser considerados como módulos porque pueden contener cualquier definición, incluidos otros objetos por supuesto y, significativamente, tipos.

Un rasgo se puede considerar como un módulo abstracto. Puede contener cualquier definición y cualquier miembro puede ser abstracto e incluir, de nuevo significativamente, miembros. Estoy recitando todo esto solo para resaltar la simetría. Tal vez OT, pero para mí los rasgos parecen ser una gran innovación en scala como la fusión de objetos e ideas funcionales.

finalmente dar una respuesta:

1. creo paquetes podrían eliminarse en favor de los objetos (no rasgos).
2. El beneficio sería una simplificación: los objetos del paquete no necesitarían definirse explícitamente.
3. Creo que los paquetes son distintos de los objetos para la compatibilidad con Java/JVM.

Algunos más comentarios: en el video Martin habla de rasgos (módulos abstractos) más que módulos concretos porque estos últimos solo aparecen en el último momento para ensamblar y reificar una combinación de módulos abstractos.

Es bueno usar módulos abstractos incluso cuando no se está "mezclando un pastel". p.ej. al esbozar algún código, puede definir un módulo para contener definiciones. Pero tan pronto como llegue a un tipo o valor que no esté listo para completar, no proporcione un maniquí como nulo.En su lugar, cambie el objeto a un rasgo y deje el miembro abstracto.