2011-08-30 25 views
19

Aparte del aspecto de la herencia, es que hay una diferencia entre las plantillas de clase:lo que es más Scala idiomática: rasgo TraitA extiende TraitB o rasgo TraitA {auto: TraitB =>}

1| trait TraitA extends TraitB 

2| trait TraitA { self: TraitB => } 

me gustaría repartir responsabilidades entre TraitA y TraitB pero la primera no puede funcionar sin la última.

¿Cómo expresarías tu intención? Para mí, la solución [2] sería el enfoque más natural. Sin embargo, no quiero poner la carga a los implementadores que se mezclan en lo que debe mezclarse de todos modos.

+0

posible duplicado de [¿Cuál es la diferencia entre los tipos de autoescala y las subclases de rasgos?] (Http://stackoverflow.com/questions/1990948/what-is-the-difference-between-scala-self-types- y-rasgo-subclases) –

Respuesta

16

Mi preferencia es generalmente [1] porque, como dices, el implementador no tiene la carga de mezclar (un subtipo de) TraitB. Quizás [2] es preferible si, por algún motivo, es deseable no heredar las implementaciones concretas en TraitB y forzar al implementador a hacer una elección entre los subtipos de TraitB. Aún así, [1] es igual de flexible.

que tienden a utilizar [2] sólo cuando es necesario, tal como cuando el tipo no es una clase conocida o rasgo,

// Here, Matrix cannot extend type parameter Repr 
trait Matrix[+Repr <: Matrix[Repr]] { self: Repr => 
    ... 
} 

Actualizar. Aquí es otra diferencia menor,

trait B 
trait A { self: B => } 
def g(ab: A): B = ab // Type mismatch: found A, required B 

Es un poco molestouna restricción opcional no ser capaz de utilizar A como B, a pesar de que el tipo se incorpora.

+2

Hablando de su actualización. Creo que la "pequeña molestia" es bastante útil para dejar que uno exprese que un 'A' coopera con" pero al mismo tiempo "no es un' B'. Para mí eso es algo así como herencia privada vs. pública respectivamente. –

+0

Ah, esa es una buena manera de pensarlo. Actualizaré de nuevo. –

+0

Históricamente, la motivación para la anotación de tipo propio es la primera diferencia; al menos, así es como esta característica está motivada en el documento * Abstracciones de componentes escalables * de Odersky & Zenger (que puede encontrar en Google Scholar, si está interesado). – Blaisorblade

Cuestiones relacionadas