Scala: Résumé des types de vs génériques

Vous avez un bon point de vue sur cette question ici:

Le But de la Scala de Type du Système

Une Conversation avec Martin Odersky, Partie III

par Bill Venners et Frank Sommers (18 Mai 2009)

Mise à jour (October2009): ce qui suit ci-dessous a été effectivement illustré dans ce nouvel article par Bill Venners:

Type abstrait Membres rapport à des Paramètres de Type Générique en Scala (voir le résumé à la fin)

---

(Voici l'extrait pertinent de la première entrevue, Mai 2009, c'est moi qui souligne)

Principe général

Il y a toujours eu deux notions d'abstraction:

• de paramétrage et d'
• membres abstraits.

En Java, vous avez également la fois, mais cela dépend de ce que vous abstraire de plus.

En Java, vous avez des méthodes abstraites, mais vous ne pouvez pas passer d'une méthode en tant que paramètre.

Vous n'avez pas le résumé, mais vous pouvez passer une valeur d'un paramètre.

Et, de même, vous n'avez pas de type abstrait membres, mais vous pouvez spécifier un type de paramètre.

Donc en Java, vous avez également tous les trois de ceux-ci, mais il y a une distinction à propos de ce principe d'abstraction que vous pouvez utiliser pour ce genre de choses. Et on pourrait dire que cette distinction est assez arbitraire.

La Scala Façon

Nous avons décidé de la mêmes principes de construction pour tous les trois sortes de membres.

Vous pouvez donc avoir le résumé ainsi que la valeur des paramètres.

Vous pouvez passer des méthodes (ou fonctions) en tant que paramètres, ou vous pouvez abstraite au-dessus d'eux.

Vous pouvez spécifier les types de paramètres, ou vous pouvez abstraite au-dessus d'eux.

Et ce que nous obtenons sur le plan conceptuel, c'est que nous pouvons modéliser l'un pour l'autre. Au moins en principe, on peut exprimer toutes sortes de paramétrage comme une forme d'abstraction orientée objet. Donc dans un sens on pourrait dire Scala est un plus orthogonale et complet de la langue.

Pourquoi?

Ce, en particulier, résumé des types de acheter de vous, c'est un joli traitement pour ces covariance des problèmes nous avons parlé auparavant.

Un problème standard, qui a été autour pendant un long moment, c'est le problème des animaux et des aliments.

Le puzzle était pour avoir une classe Animal avec une méthode, eat, qui mange de la nourriture.

Le problème est que si nous sous-classe des Animaux et ont une classe de Vache, alors ils ne mangent que de l'Herbe et non arbitraire de la nourriture. Une Vache ne pouvais pas manger un Poisson, par exemple.

Ce que vous voulez est d'être en mesure de dire que la Vache a un manger méthode qui ne mange que de l'Herbe et pas autres choses.

En fait, vous ne pouvez pas le faire en Java, car il s'avère, vous pouvez construire des situations malsaines, comme le problème de l'attribution d'un Fruit à un Apple variable dont j'ai parlé plus tôt.

La réponse est que vous ajoutez un type abstrait dans l'Animal de la classe.

Vous dire, mon nouvel Animal de la classe a un type de SuitableFood, qui je ne sais pas.

C'est donc un type abstrait. Vous ne donnez pas une mise en œuvre de ce type. Ensuite, vous avez une eat méthode qui ne mange que de SuitableFood.

Et puis, dans la Cow classe, je dirais, OK, j'ai une Vache, qui s'étend de la classe Animal, et pour Cow type SuitableFood equals Grass.

Donc résumé des types de fournir cette notion de type dans une super-classe que je ne connais pas, que j'ai ensuite remplir plus tard dans les sous-classes de quelque chose, je ne sais.

Même avec un paramétrage?

En effet vous pouvez. Vous pouvez paramétrer la classe Animal avec le genre de nourriture qu'il mange.

Mais dans la pratique, lorsque vous le faites avec beaucoup de choses différentes, elle conduit à une explosion de paramètres, et généralement, ce qui est plus, dans limites des paramètres.

En 1998 ECOOP, Kim Bruce, Phil Wadler, et j'ai eu un papier où nous avons montré que comme vous augmentez le nombre de choses que vous ne savez pas, le programme typique va croître quadratiquement.

Il y a donc de très bonnes raisons de ne pas faire de paramètres, mais ces membres abstraits, parce qu'ils ne vous donnent pas cette quadratique exploser.

---

thatismatt demande dans les commentaires:

Pensez-vous de ce qui suit est un résumé fidèle:

• Résumé Types sont utilisés dans 'a-a' ou 'utilise une relation (par exemple un Cow eats Grass)
• où les génériques sont généralement des relations (par exemple List of Ints)

Je ne suis pas sûr que la relation qui existe entre l'utilisation de résumé ou de types génériques.
Ce qui est différent est:

• la façon dont ils sont utilisés, et
• comment paramètre limites sont gérés.

---

De comprendre ce que Martin est de parler de quand il s'agit de "l'explosion de paramètres, et généralement, ce qui est plus, dans limites des paramètres", et son quadratiquement de la croissance lorsque le type abstrait sont modélisés à l'aide de médicaments génériques, vous pouvez envisager le papier "Évolutive Composant Abstraction" écrit par... Martin Odersky, et Matthias Zenger pour OOPSLA 2005, référencé dans le publications du projet Palcom (terminé en 2007).

Des extraits pertinents

Définition

Type abstrait membres fournir un moyen souple de résumé sur le béton des types de composants.

Résumé types peuvent cacher des informations sur le fonctionnement interne d'un composant, semblable à leur utilisation dans SML signatures. Dans un framework orienté objet où les classes peuvent être étendues par héritage, ils peuvent également être utilisés comme un moyen flexible de paramétrage (souvent appelé famille polymorphisme, voir ce blog par exemple, et le papier écrit par Eric Ernst).

(Note: la Famille polymorphisme a été proposé pour les langages orientés objet comme une solution à l'appui réutilisables encore de type sécurisé mutuellement récursives classes.

Une idée clé de la famille polymorphisme est la notion de famille, qui sont utilisés pour groupe mutuellement récursives classes)

délimitée type d'abstraction

abstract class MaxCell extends AbsCell {
type T <: Ordered { type O = T }
def setMax(x: T) = if (get < x) set(x)
}

Ici, le de la déclaration de type de T est contraint par un supérieur de type lié qui se compose d'un nom de classe Ordonnée et un raffinement { type O = T }.

La limite supérieure limite les spécialisations de la T dans les sous-classes de ces sous-types de l'ordre pour lequel le membre de type O de equals T.

En raison de cette contrainte, l' < méthode de classe Ordonnée est garanti pour être applicable à un récepteur et un argument de type T.

L'exemple montre que le délimitée type de membre peut apparaître comme une partie du lié.

(c'est à dire Scala prend en charge F-bornée polymorphisme)

(Remarque, de la part de Pierre de mise en conserve, William Cook, Walter Hill, Walter Olthoff papier:

Délimitée quantification a été introduit par Cardelli et Wegner comme un moyen de taper des fonctions qui opèrent de manière uniforme sur tous les sous-types d'un type donné.

Ils ont défini un simple "objet" modèle et utilisé délimitée quantification par type de fonctions de contrôle qui ont du sens sur tous les objets ayant un ensemble spécifié de "attributs".

Une présentation plus réaliste des langages orientés objet permettrait à des objets qui sont des éléments de de manière récursive les types définis par l'.

Dans ce contexte, dans les limites de quantification ne sert plus à sa destination. Il est facile de trouver les fonctions qui a du sens sur tous les objets ayant un ensemble de méthodes, mais qui ne peuvent pas être saisis dans le Cardelli-Wegner système.

Pour fournir une base pour tapé fonctions polymorphes dans les langages orientés objet, nous introduisons F-bornée quantification)

Deux faces d'une même pièces

Il existe deux principales formes de l'abstraction dans les langages de programmation:

• de paramétrage et d'
• membres abstraits.

La première forme est typique pour les langages fonctionnels, tandis que la deuxième forme est généralement utilisée dans les langages orientés objet.

Traditionnellement, Java prend en charge le paramétrage de valeurs, et membre de l'abstraction pour les opérations.
La plus récente de Java 5.0 avec les génériques prend en charge le paramétrage également pour les types.

Les arguments, y compris pour les médicaments génériques en Scala sont de deux ordres:

• Tout d'abord, l'encodage dans l'abstrait n'est pas si simple à faire à la main. En plus de la perte de la concision, il y a aussi le problème des accidents de nom
  les conflits entre l'abstrait type de noms qui émulent des paramètres de type.

• Deuxième, génériques et abstraits types habitude de servir des rôles distincts dans la Scala de programmes.

  • Génériques sont généralement utilisés lorsque l'on a juste besoin d' type d'instanciation, alors que
  • résumé types sont généralement utilisés quand on a besoin d' reportez-vous à l'abstrait
    type de client code.
    
    Ce dernier se pose en particulier dans deux cas:
  • Que l'on peut vouloir cacher la définition exacte d'un membre de type de code client, afin d'obtenir une sorte d'encapsulation connu de SML de style systèmes de modules.
  • Ou peut-être judicieux de remplacer le type covariantly dans les sous-classes pour obtenir de la famille de polymorphisme.

Dans un système délimité polymorphisme, la réécriture de type abstrait dans les génériques pourrait entraîner une quadratique extension de type de limites.

---

Mise À Jour Octobre 2009

Type abstrait Membres rapport à des Paramètres de Type Générique en Scala (Bill Venners)

(l'emphase est mienne)

Mon observation jusqu'à présent sur type abstrait membres, c'est qu'ils sont principalement un meilleur choix que les paramètres de type générique lorsque:

• vous souhaitez laisser les gens mélange dans les définitions de ces types via traits.
• vous pensez que le mention explicite du type de nom de membre lorsqu'il est défini pour aider à la lisibilité du code.

Exemple:

si vous souhaitez passer trois différents luminaire d'objets dans les tests, vous serez en mesure de le faire, mais vous aurez besoin de spécifier trois types, un pour chaque paramètre. Ainsi avais-je pris le paramètre du type d'approche, l'ensemble des classes ont fini par ressembler à ceci:

//Type parameter version
class MySuite extends FixtureSuite3[StringBuilder, ListBuffer, Stack] with MyHandyFixture {
  //...
}

Alors qu'avec le type de membre approche, il ressemblera à ceci:

//Type member version
class MySuite extends FixtureSuite3 with MyHandyFixture {
  //...
}

Une autre différence mineure entre le type abstrait des membres et des paramètres de type générique, c'est que lorsqu'un paramètre de type générique est spécifié, les lecteurs de code ne voyez pas le nom du paramètre de type. Ainsi, quelqu'un de voir cette ligne de code:

//Type parameter version
class MySuite extends FixtureSuite[StringBuilder] with StringBuilderFixture {
  //...
}

Ils ne savent pas quel est le nom du type de paramètre spécifié comme StringBuilder était sans regarder. Alors que le nom du paramètre type est là, dans le code du type abstrait membre approche:

//Type member version
class MySuite extends FixtureSuite with StringBuilderFixture {
  type FixtureParam = StringBuilder
  //...
}

Dans ce dernier cas, les lecteurs de code ne pouvaient voir que StringBuilder est le "fixture paramètre" type de.

Ils ont encore besoin de comprendre à quel "fixture paramètre" signifiait, mais ils pourraient au moins avoir le nom du type sans regarder dans la documentation.

Vous pouvez utiliser les types abstract en conjonction avec les paramètres de type d'établir des modèles personnalisés.

Imaginons que vous avez besoin d'établir un modèle connecté avec trois traits:

trait AA[B,C]
trait BB[C,A]
trait CC[A,B]

dans la façon dont les arguments mentionnés dans les paramètres de type AA,BB,CC lui-même respectueusement

Vous pouvez venir avec un certain type de code:

trait AA[B<:BB[C,AA[B,C]],C<:CC[AA[B,C],B]]
trait BB[C<:CC[A,BB[C,A]],A<:AA[BB[C,A],C]]
trait CC[A<:AA[B,CC[A,B]],B<:BB[CC[A,B],A]]

qui ne fonctionne pas de cette manière simple, en raison de paramètre de type d'obligations. Vous devez il covariante d'hériter correctement

trait AA[+B<:BB[C,AA[B,C]],+C<:CC[AA[B,C],B]]
trait BB[+C<:CC[A,BB[C,A]],+A<:AA[BB[C,A],C]]
trait CC[+A<:AA[B,CC[A,B]],+B<:BB[CC[A,B],A]]

Présente un échantillon de la compilation, mais elle fixe des exigences fortes sur la variance des règles et ne peut pas être utilisé dans certaines occasions

trait AA[+B<:BB[C,AA[B,C]],+C<:CC[AA[B,C],B]] {
  def forth(x:B):C
  def back(x:C):B
}
trait BB[+C<:CC[A,BB[C,A]],+A<:AA[BB[C,A],C]] {
  def forth(x:C):A
  def back(x:A):C
}
trait CC[+A<:AA[B,CC[A,B]],+B<:BB[CC[A,B],A]] {
  def forth(x:A):B
  def back(x:B):A
}

Le compilateur objet avec des tas de variance vérifier les erreurs

Dans ce cas, vous peut recueillir toutes les exigences de type supplémentaire de traits de caractère et de paramétrer d'autres traits plus il

//one trait to rule them all
trait OO[O <: OO[O]] { this : O =>
type A <: AA[O]
type B <: BB[O]
type C <: CC[O]
}
trait AA[O <: OO[O]] { this : O#A =>
type A = O#A
type B = O#B
type C = O#C
def left(l:B):C
def right(r:C):B = r.left(this)
def join(l:B, r:C):A
def double(l:B, r:C):A = this.join( l.join(r,this), r.join(this,l) )
}
trait BB[O <: OO[O]] { this : O#B =>
type A = O#A
type B = O#B
type C = O#C
def left(l:C):A
def right(r:A):C = r.left(this)
def join(l:C, r:A):B
def double(l:C, r:A):B = this.join( l.join(r,this), r.join(this,l) )
}
trait CC[O <: OO[O]] { this : O#C =>
type A = O#A
type B = O#B
type C = O#C
def left(l:A):B
def right(r:B):A = r.left(this)
def join(l:A, r:B):C
def double(l:A, r:B):C = this.join( l.join(r,this), r.join(this,l) )
}

Maintenant, nous pouvons écrire en béton pour la représentation des modèles décrits, définir la gauche et rejoindre les méthodes de toutes les classes et obtenir le droit et le double pour gratuit

class ReprO extends OO[ReprO] {
override type A = ReprA
override type B = ReprB
override type C = ReprC
}
case class ReprA(data : Int) extends AA[ReprO] {
override def left(l:B):C = ReprC(data - l.data)
override def join(l:B, r:C) = ReprA(l.data + r.data)
}
case class ReprB(data : Int) extends BB[ReprO] {
override def left(l:C):A = ReprA(data - l.data)
override def join(l:C, r:A):B = ReprB(l.data + r.data)
}
case class ReprC(data : Int) extends CC[ReprO] {
override def left(l:A):B = ReprB(data - l.data)
override def join(l:A, r:B):C = ReprC(l.data + r.data)
}

Donc, à la fois abstrait types de paramètres de type et sont utilisés pour créer des abstractions. Ils ont tous deux faibles et points forts. Résumé types sont plus spécifiques et capables de décrire tout type de structure, mais il est verbeux et nécessitent explicite spécifiée. Les paramètres de Type peut créer des tas de types instantanément, mais vous donne plus de s'inquiéter à propos de l'héritage et le type de limites.

Ils donnent synergie les uns des autres et peuvent être utilisés conjointement pour créer des complexes des abstractions qui ne peut pas être exprimée par un seul d'entre eux.