Что еще более идиоматично в Scala: trait TraitA extends TraitB or trait TraitA { self: TraitB =› }

Помимо аспекта наследования, есть ли разница между следующими шаблонами классов:

1| trait TraitA extends TraitB

2| trait TraitA { self: TraitB => }

Я хотел бы разделить обязанности между TraitA и TraitB, но первый не может работать без второго.

Как бы вы выразили это намерение? Для меня решение [2] было бы более естественным подходом. Однако я не хочу возлагать бремя на разработчиков, смешивающих то, что нужно смешать в любом случае.


person Tim Friske    schedule 30.08.2011    source источник
comment
возможный дубликат В чем разница между scala self -типы и подклассы признаков?   -  person om-nom-nom    schedule 08.01.2013


Ответы (1)


Обычно я предпочитаю [1], потому что, как вы говорите, разработчик не обязан смешивать (подтип) TraitB. Возможно, [2] предпочтительнее, если по какой-то причине желательно не наследовать конкретные реализации в TraitB и заставлять разработчика делать выбор среди подтипов TraitB. Тем не менее, [1] такой же гибкий.

Я склонен использовать [2] только там, где это необходимо, например, когда тип не является известным классом или свойством,

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

Обновление. Еще одно небольшое отличие.

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

немного раздражает необязательное ограничение, заключающееся в том, что нельзя использовать A как B, даже если этот тип включен.

person Kipton Barros    schedule 30.08.2011
comment
Кстати о вашем обновлении. Я думаю, что небольшое раздражение весьма полезно, чтобы выразить, что A сотрудничает с, но в то же время не является B. Для меня это похоже на частное и публичное наследование соответственно. - person Tim Friske; 01.09.2011
comment
Исторически сложилось так, что мотивация для аннотаций собственного типа является первым отличием — по крайней мере, именно так эта функция мотивирована в статье Scalable Component Abstractions Odersky&Zenger (которую вы можете найти в Google Scholar, если интересно) . - person Blaisorblade; 02.07.2012