Puzzle - Verfügbarmachen eines öffentlichen Unterelements eines privaten Mitglieds mit einem benutzerdefinierten Typ

8

Ich würde gerne so etwas machen (Beispiel ist vereinfacht, enthält aber alle entscheidenden Teile):

%Vor%

Und hier (*) bekomme ich einen Fehler:

  

Der private Wertmaster entzieht seinen definierenden Bereich als Teil des Typs   Slave.this.master.DataType

     

val counter = master.counter

Ich verstehe den Fehler, aber ich verstehe den Grund nicht - der Typ ist Teil der Klasse Master , nicht das Objekt master , daher ist es wichtig, dass die Klasse privat ist, kein Objekt. Nun, zumindest in der Theorie.

Es ist leicht, eine schnelle Abhilfe zu schaffen:

%Vor%

Aber ich glaube, das ist eine explizite Version des exakt gleichen Codes wie zuvor, es "braucht" nur mehr Eingabe. Ist das ein Feature?

FRAGE:

Kann ein Typ (hier DataType) abhängig vom Objekt und nicht von der Klasse (d. h. Typdefinition pro Instanz der Klasse) in Scala?

sein     
greenoldman 01.01.2012, 20:53
quelle

1 Antwort

14

Sie irren sich, wenn Sie denken

  

Dies ist eine explizite Version des exakt gleichen Codes wie zuvor

Master#DataType und master.DataType sind zwei verschiedene Typen.

master.DataType ist der Typ dieser DataType Instanzen, die master als äußeres Objekt haben. Mit anderen Worten, genau das, was Sie fragen, aber offensichtlich ist dann master Teil des Typs, und der Typ kann nicht offengelegt werden, wenn master nicht ist.

Master#DataType ist der Typ einer beliebigen DataType -Instanz für ein beliebiges äußeres Objekt (entspricht Master.DataType in Java).

ANTWORT AUF DEN KOMMENTAR:

Type-Member können in einer Unterklasse überschrieben werden (einschließlich einer anonymen Subklasse, die nur ein Objekt enthält), jedoch nur nach einem kompatiblen Typ. Und in deinem Beispiel ist DataType in Master bereits konkret, also ist die einzige kompatible Klasse mit ihr selbst. So etwas wie

%Vor%

wird nicht typencheck, was sinnvoll ist: Sie würden var counter: String = 0 bekommen, was Unsinn ist. Aber

%Vor%

funktioniert (ist aber nicht sehr nützlich).

Es macht also immer nur Sinn, abstrakte Typ-Member zu überschreiben. Aber sie werden genau wie innere Klassen typgeprüft, so dass a.DataType im Allgemeinen nicht als b.DataType betrachtet wird - auch wenn sie nicht wirklich anders sein können!

    
Alexey Romanov 01.01.2012, 21:32
quelle

Tags und Links