Exemple de contravariance

Question

Je pense à l'exemple suivant pour illustrer l'utilité de la contravariance.

Considérons un cadre d'interface graphique avec Widgets , Events y Event Listeners .

abstract class Event;
class KeyEvent extends Event
class MouseEvent extends Event

trait EventListener[-E] { def listen(e:E) }

Sea Widgets définissent les méthodes suivantes :

def addKeyEventListener(listener:EventListener[KeyEvent])
def addMouseEventListener(listener:EventListener[MouseEvent])

Ces méthodes n'acceptent que des récepteurs d'événements "spécifiques", ce qui est très bien. Cependant, j'aimerais définir également des auditeurs de type "kitchen-sink", qui écoutent tous les événements, et transmettre ces auditeurs aux méthodes "add listener" ci-dessus.

Par exemple, je voudrais définir LogEventListener pour enregistrer tous les événements entrants

class LogEventListener extends EventListener[Event] {
   def listen(e:Event) { log(event) }
}

Étant donné que le trait EventListener es contravariant en Event nous pouvons passer LogEventListener à toutes ces méthodes "ajouter un auditeur" sans perdre leur sécurité de type.

Cela a-t-il un sens ?

Answer 1

Pour moi, c'est logique. C'est aussi l'un des exemples les plus intuitifs que j'aie vus : quelque chose qui écoute tous les événements écoutera naturellement les événements liés aux touches ou à la souris.

Answer 2

Pour moi aussi, c'est une question de bon sens. En règle générale, un type paramétré Type[A] doit être contravariante par rapport à son paramètre de type A chaque fois qu'il est censé accepter des instances de A d'en faire quelque chose en les acceptant comme paramètres .

Par exemple, le type Java Comparator[T] s'il avait été défini en Scala, aurait été contravariant : un Comparator[Any] doit être un sous-type de Comparator[String] car il peut comparer tous les objets a Comparator[String] peuvent être comparés, et plus encore. L'exemple le plus général est celui des types d'arguments de la méthode FunctionX qui sont toutes contravariantes.