Warum ist es sicher, Objekt-private oder Objekt-geschützte Definitionen nicht für ihre Varianzposition zu überprüfen?

Question

Ich habe gelernt, dass Scala Objekt-private (private[this]) oder Objekt-geschützte (protected[this]) Definitionen für ihre Varianz-Position nicht überprüft. Warum ist es sicher, sie nicht zu überprüfen?

Ich habe einige damit verbundene Materialien gelesen, konnte aber noch keine vollständige Antwort finden. . Zuerst Odersky, et al die „Programmierung in Scala“, sagt:

http://www.artima.com/pins1ed/type-parameterization.html#19.7

Es stellt sich heraus, dass die Zugriffe auf Variablen aus dem gleichen Objekt, in dem sie definiert sind keine Probleme mit der Varianz verursachen. Die intuitive Erklärung ist, dass, um einen Fall zu konstruieren, in dem Varianz zu Typfehlern führt, ein Verweis auf ein enthaltendes Objekt erforderlich ist, das einen statisch schwächeren Typ als den Typ aufweist, mit dem das Objekt definiert wurde.

Ich bin nicht sicher, genau zu wissen, was die Autoren bedeuten durch „ein Objekt enthält“ und „ein statisch schwächeren Typ“. Ein Codebeispiel wäre hier vorzuziehen.

Zweitens, "senia" gab ein gutes Beispiel in Scala Modifiers and Type parametrization, die zeigt, welches Problem Klasse-private (private) Felder mit Varianz haben können. Das Beispiel überzeugt mich, warum class-private Mitglieder auf ihre Varianzpositionen überprüft werden sollten, gab aber keine Antwort auf den Grund, warum wir Objekt-private/geschützte Definitionen nicht überprüfen müssen. Ich verstehe, dass ein solcher Code wie getOtherCache() nicht mit Objekt-private Felder geschrieben werden kann. Aber es gibt keinen Beweis für die Unschädlichkeit von objekt-privaten/projizierten Definitionen, dass wir kein Programm geschrieben haben, dass objekt-private/projizierte Definitionen Probleme mit der Varianz verursachen.

Drittens Michid das Thema kurz erwähnt, während decsribing wie Funktion memoization in Scala zu implementieren:

http://michid.wordpress.com/2009/02/23/function_mem/

class Memoize1[-T, +R](f: T => R) extends (T => R) { 
    ... 
    private[this] val vals = mutable.Map.empty[T, R] 
    ... 
} 

jedoch nur von seiner enthält Instanz zugegriffen, da vals, kann es nicht zu Problemen führen mit Abweichung.

Leider beantwortet es meine Frage nicht "wie (oder warum) ist die Zugriffskontrolle auf Varianz bezogen?".

Können Sie näher erklären, warum Objekt-private/geschützte Definitionen nicht auf ihre Varianzposition hin überprüft werden (oder Referenzen geben)? nur

Answer 1

Probleme mit Varianz auftreten, wenn die Übersetzungszeit und Laufzeit-Typ eines Objekts unterscheiden:

val a: List[Any] = List("foo"): List[String] 

a Hier hat eine statisch schwächeren Typ (List[Any]) als definiert (List[String]). Ferner gilt das Gleiche für ein enthaltendes Objekt (d. H. Ein Element der Liste). (Statischer Typ Any, definierter Typ String).

Wenn wir Objekt-private (oder Objektschutz) Felder haben, kann diese Situation nicht auftreten:

trait A[-T] { 
    protected[this] val x: T 
} 

Wenn wir x zugreifen können wir sicher sein, es tatsächlich vom Typ T, auch wenn A contra ist -Variant, da die this Referenz nicht irgendwo hochgerechnet werden kann. (Wir kennen unseren Selbsttyp immer vollständig).

Wenn wir also hier Odersky Worte zurück, lassen Sie uns einen Blick auf:

val cont: A[String] = new A[Any] { ... } 
cont.x // BAD! Is `Any`, not `String` 

cont ist ein Verweis auf ein Objekt, das statisch schwächeren Typ hat als mit definiert, deshalb der Hinweis auf x ist nicht erlaubt. Diese heraufgestufte Situation wird nicht mit diesem Zeiger auftreten, daher ist das Folgende in Ordnung:

trait B[-T] extends A[T] { 
    def foo() { 
    // here, this has always the most specific type. 
    val tmp: T = this.x 
    // do stuff 
    } 
}