scala générique de la redéfinition de méthode

J'ai une classe abstraite :

abstract class Foo(...){
   def bar1(f : Foo) : Boolean
   def bar2(f : Foo) : Foo
}

plusieurs classes d'étendre Foo et surcharger les méthodes

class FooImpl(...) extends Foo{
    override def bar1(f : Foo) : Boolean {
        ...
    }
    override def bar2(f : Foo) : Foo {
        ...
    }
}

Est-il possible, à l'aide de médicaments génériques (ou quelque chose) pour faire de la redéfinition des méthodes ont la parametertype de la sous-classe de la mettre en œuvre? Comme ceci :

class FooImpl(...) extends Foo{
    override def bar1(f : FooImpl) : Boolean {
        ...
    }
    override def bar2(f : FooImpl) : FooImpl {
        ...
    }
}

Je pensais à quelque chose le long de la ligne de la suite, mais cela ne semble pas fonctionner...

abstract class Foo(...){
    def bar1[T <: Foo](f : T) : Boolean
    def bar2[T <: Foo](f : T) : T
}

class FooImpl(...) extends Foo{
    override def bar1[FooImpl](f : FooImpl) : Boolean {
       ...
    }
    override def bar2[FooImpl](f : FooImpl) : FooImpl{
       ...
    }
}

Toute aide est très appréciée!

Merci.

OriginalL'auteur Jannik Luyten | 2011-01-07

20
```
abstract class Foo{
   type T <: Foo
   def bar1(f:T):Boolean
   def bar2(f:T):T
}

class FooImpl extends Foo{
   type T = FooImpl
   override def bar1(f:FooImpl) = true
   override def bar2(f:FooImpl) = f
}
```
Dans cette version, les différentes sous-classes de Foo partageons tous Foo comme une super-classe, mais de tenir la valeur de retour de bar2 (ou les paramètres de bar1 ou bar2) dans un contexte où tout ce que vous savez au sujet de votre objet (disons que c'est nommée obj), c'est que c'est un Foo, vous devez utiliser le type obj.T que le type de la variable.

Ce qui a rendu possible ce que j'ai l'intention de le faire. Ainsi, en utilisant le type "T <: Foo", j'ai créer un type T qui est soit Foo ou l'un quelconque de ses sous-classes, et je peux alors utiliser ce type au sein de la classe comme n'importe quel autre type, d'où je veux. Soit en tant que paramètre, var type de valeur de retour, ... Correct? Je vous remercie beaucoup. Sur une note; je suis agréablement surpris de la rapidité des réponses à ce post. Coup de chapeau 🙂
Vous êtes correct.

OriginalL'auteur Ken Bloom

De faire Ken Blum deuxième version un peu plus agréable, vous pouvez utiliser l'auto types:

abstract class Foo[T] { self:T =>
   def bar1(f:T):Boolean
   def bar2(f:T):T
}

class FooImpl extends Foo[FooImpl]{
   override def bar1(f:FooImpl) = true
   override def bar2(f:FooImpl) = f
}

OriginalL'auteur Landei

2

T doit être un type de paramètre sur la Foo classe que vous héritez de, pas sur les méthodes elles-mêmes.
```
abstract class Foo[T <: Foo[T]]{
   def bar1(f:T):Boolean
   def bar2(f:T):T
}

class FooImpl extends Foo[FooImpl]{
   override def bar1(f:FooImpl) = true
   override def bar2(f:FooImpl) = f
}
```
Différentes sous-classes de Foo n'ont pas réellement d'un commun supertype dans cette version du code, car ils s'étendent à partir de différents paramétrages de Foo. Vous pouvez utiliser paramétrée méthodes qui renvoient à Foo[T] lorsque vous avez besoin de travailler avec le supertype, mais j'ai tendance à préférer le type abstrait solution que j'ai posté dans mon autre réponse, car il n'y a pas de fuite les détails de l'génériques pour toutes les autres fonctions qui ont à traiter avec des Foos.

OriginalL'auteur Ken Bloom

Idéalement, vous combinez les choses mentionnées ci-dessus, c'est à dire

trait Foo[T <: Foo[T]] { self:T =>

"[T <: Foo[T]]" signifie T est une sous-classe de Foo[T],
ET "l'auto:T =>" signifie que les Foo[T] est sous-classe de T, et, ensemble, c'est un peu bizarre façon de dire que Foo[T] est exactement le même que T.

Seul avec qui j'ai pu faire code suivant compile et fonctionne comme prévu:

trait Field[T <: Field[T]] { self:T =>

  def x2:T

  def +(that:T):T

  def *(n:BigInt) : T = {
    if(n == 1)
      this
    else if(n == 2)
      this.x2
    else if(n == 3)
      this + this.x2
    else {
      val p = (this * (n/2)).x2
      if (n%2==0)
        p
      else
        p + this
    }        
  }

}

OriginalL'auteur Baturinsky

0

Vous pouvez paramétrer Foo d'accomplir une partie de l'effet facilement:
```
abstract class Foo[F <: Foo[F]] { def f: F }
class Food extends Foo[Food] { def f = this }  //Yay!
class Fool extends Foo[Food] { def f = new Food }  //Uh-oh...
```
Si vous voulez exclure le second cas, il n'y a pas de façon simple de le faire avec les caractéristiques actuelles en Scala.

Aussi, une partie de ce que vous semblez vouloir ne fait pas de sens si vous donner une mise en œuvre effective dans Foo. Si Foo promet de prendre toute Foo mais vous donner une méthode qui insiste sur seulement un Food, il va se casser si vous vous passez à une autre sous-classe de Foo (par exemple Fool). Ainsi, le compilateur ne te laisserai pas faire ça.
```
abstract class Foo { def bar(f: Foo) : Foo }
class Foot extends Foo { def bar(f: Foo) = this }   //Fine!
class Fool extends Foo { def bar(f: Fool) = this }   //No good!
```
Je pense que nous pouvons faire confiance au programmeur de ne pas définir Fool comme un Foo[Food] moins c'est ce qu'il souhaite réellement.
Je pense que nous pouvons faire confiance au programmeur de ne pas l'intention de définir Fool comme un Foo[Food], mais les erreurs se produisent. Si des erreurs n'a pas eu lieu, nous n'aurions probablement pas besoin de la vérification de type à tous 🙂

OriginalL'auteur Rex Kerr

Vous devez vous connecter pour publier un commentaire.