2014-10-03 9 views
7

Wir haben ein typisches Getter in einem unsere Klassen, sagen sieTypeScript Interface-Signatur für Eigenschaft ohne Setter.

class Employee implements IEmployee { 
    private _fullName: string; 

    get fullName(): string { 
     return this._fullName; 
    } 
} 

und eine Schnittstelle mit ihm

interface IEmployee{ 
    fullName: string; 
} 

zu arbeiten, wenn mit einer Instanz über diese Schnittstelle der Compiler arbeiten werden uns nicht warnen über das Fehlen eines Settors, wenn wir versuchen, fullName zuzuweisen, und die JS-Laufzeit schluckt einfach jede Zuweisung und wirft keinen Fehler. Gibt es eine Möglichkeit, das Interface-Mitglied als Getter oder nur als Setter zu markieren?

Ich habe gesehen this post, aber es ist ziemlich alt, ich möchte wissen, wenn überhaupt etwas verbessert.

+0

Wirklich überrascht über den Mangel an Aktivität für diese Frage. Schreibgeschützte Eigenschaften sind unglaublich nützlich und eines der ersten Muster, das ich in TypeScript zu implementieren versuchte. – gravidThoughts

Antwort

1

Dies ist eine interessante Frage. Das Konzept einer schreibgeschützten Eigenschaft unterscheidet sich in TypeScript subtil von anderen Sprachen.

In vielen Sprachen würde eine Eigenschaft mit einem Getter (aber ohne Setter) einen Compilerfehler auslösen, wenn Sie versuchen, die Eigenschaft zu setzen, aber TypeScript nicht.

Die Eigenschaft ist immer noch schreibgeschützt, da es keinen Unterschied macht, wenn Sie versuchen, sie festzulegen. Das Set wird im Hintergrund ausfallen. Hier

ist ein Beispiel ohne Schnittstellen:

class Example { 
    get name() { 
     return 'Steve'; 
    } 
} 

var y = new Example(); 
y.name = 'Example 2'; 
alert(y.name); 

Es gibt keine Compiler-Warnung, wenn ich x.name = 'Example 2'; verwenden.

Wenn dort war eine Compiler-Warnung, würde ich später erwarten, dass es eine Möglichkeit gibt, die Readonly-Ness einer Eigenschaft innerhalb einer Schnittstelle anzugeben. Wie Sie jedoch erwarten können, können Sie aufgrund der obigen Informationen keine schreibgeschützte Eigenschaft für eine Schnittstelle festlegen.

interface Test { 
    name: string; 
} 

class Example { 
    get name() { 
     return 'Steve'; 
    } 
} 

var x: Test = new Example(); 
x.name = 'Example 1'; 
alert(x.name); 

var y = new Example(); 
x.name = 'Example 2'; 
alert(x.name); 

Dies bedeutet, dass Sie nur eine Methode, indem man den Wert der Eigenschaft (und offensichtlich keine Methode, die es gesetzt werden kann) bekommen Read-only-ness erzwingen können.

interface Test { 
    getName:() => string; 
} 

class Example { 
    getName() { 
     return 'Steve'; 
    } 
} 

var x: Test = new Example(); 
//x.getName('Obviously not'); 
//x.getName() = 'Obviously not'; 
alert(x.getName()); 

var y = new Example(); 
//y.getName('Obviously not'); 
//y.getName() = 'Obviously not'; 
alert(y.getName()); 
+0

Readonlyness wird bereits durch das JS-Verhalten in Abwesenheit eines Setter erzwungen. Das Problem ist seine stille Natur - leise den Wert schlucken. Ideale (und hoffentlich kommende) Lösung würde es TS-Interface-Mitgliedern ermöglichen, als nur getter \ setter gekennzeichnet zu haben. Eine Alternative wäre, wenn der Transpiler in Abwesenheit davon einen leeren Getter-Setter erzeugt, was einfach einen Fehler auslösen würde (zumindest für einen Setter ist dies das Verhalten, das unser gesamtes Team erwartet hat). Die letzte langweilige Lösung wäre, immer einen Wurfsetzer von Hand zu machen, wenn kein tatsächlicher Setzer benötigt wird. –

+0

'Readonlyness wird bereits durch das JS-Verhalten in Abwesenheit eines Setter ziemlich erzwungen." Ja - obwohl ich durch "erzwungen" mehr über eine Compiler-Warnung, verschnörkelte rote Linien und irgendeine Art von akustischem Alarm gesprochen habe. Der Beispielcode zeigt die stille Verwerfung des Set-Versuchs. In der Zwischenzeit ist die Verwendung einer Methode für den Zugriff auf Eigenschaften der einzige Weg, um Kompilierzeitgarantien zu erhalten, dass kein Satzversuch versucht wird. – Fenton

+0

Hat ein Problem mit GitHub zu diesem Problem gemacht https://github.com/Microsoft/TypeScript/issues/814 –