Блог

Канонический пример исправления ковариантного в остальном класса выглядит следующим образом:

стек абстрактного класса[ A] { 
 def push[B >: A]( x: B) : Стек[B]
 определение сверху: A 
 всплывающее окно определения: Стек[A]

Теперь, если я удалю неявную ковариацию и вручную аннотирую класс, я получу это:

стек абстрактного класса[A] { 
 def push[B >: A]( x: B) : Стек[B]
 def top [B >: A]: B 
 def pop [B>: A]: Стек[B]
 приведение def[B>: A]: Stack[B]
}

(Быстрое доказательство правильности: a Stack[A] содержит элементы типа A , поэтому, если B более допустимо, мы всегда можем вернуть A вместо B . Аналогично, учитывая любой стек A , мы можем использовать его вместо стека B , если B может принимать A.)

Но теперь я немного сбит с толку: где-то здесь должна быть контравариантность, но все отношения подтипов здесь кажутся одинаковыми. Что произошло?

Чтобы уточнить больше, мы определяем контравариантный функтор, F такой, что (a -> b) -> (F b -> F a) . В частности, функтор F a на a -> r контравариантен, так как (a -> b) -> ((b -> r) -> (a -> r)) просто состоит из функций. С точки зрения формализма, я ожидаю, что стрелки будут переворачиваться. Итак, с чисто синтаксической точки зрения, я запутываюсь, когда стрелки не переключаются (но они должны быть!) Является ли мой аннотированный способ написания Scala просто «естественным» представлением контравариантности функций, таким, что вы этого даже не замечаете? Мой абстрактный класс неправильный? Есть ли что-то вводящее в заблуждение во второй презентации?

Вы смотрите на ту же взаимосвязь. Давайте подумаем о том, что Stack[ A] означает: если C является подклассом A , то Stack[C] обрабатывается как подкласс Stack[A] , т. Е. он может заменять class A где угодно; поскольку все методы аннотируются обобщениями надмножества, это, конечно, верно, как вы указали.

Но вы не разработали свой исходный класс таким образом, чтобы аргумент push находился в контравариантной позиции. Эти отношения естественным образом возникают, когда вы накладываете ограничения на то, что вы можете обрабатывать — тогда, если подкласс означает, что метод может обрабатывать меньше, C[Subclass] действует как суперкласс, C[Original] поскольку C[Original] может обрабатывать все, что может обрабатывать подкласс (и даже больше). Но push может обрабатывать все так, как вы это определили.

Итак, именно так взаимодействуют границы типа и дисперсия: если вы разрешаете расширение типа именно в тех местах, которые находятся в контравариантном положении (т. Е. Которые в противном случае ограничили бы вас), тогда вам разрешено быть ковариантным. В противном случае вы должны быть инвариантными или контравариантными. (Pop не позволяет вам быть контравариантным, поэтому вам пришлось бы быть инвариантным. Посмотрите, например, на изменяемые коллекции, где инвариантность является нормой именно по этой причине — вы не можете свободно расширять тип при нажатии.)