2016-12-30 5 views
3

は単純なプログラムです:typescriptにインターフェイスでカスタムシンボルを使用する際に制限があるのはなぜですか?ここで

const mySymbol = Symbol(); 
interface Fails { 
    [mySymbol]: boolean; 
} 

interface Succeeds { 
    [Symbol.hasInstance]: boolean; 
} 

そして、ここではcomplingから出力されます:

$ tsc --lib es6 odd.ts 
odd.ts(3,3): error TS1169: A computed property name in an interface must directly refer to a built-in symbol. 

エラーは、組み込みのシンボルは活字体界面特性のタイプとして使用することができることを、理解できます、これは任意の制限のようです。

なぜこの制限が存在するのか説明できますか?

答えて

3

は、いくつかのコードを考えてみましょう:

// Implementation not visible to us 
declare function getSymbol(): Symbol; 

const s1 = getSymbol(); 
const s2 = getSymbol(); 

interface Type1 { 
    [s1]: string; 
    [s2]: number; 
} 

は、法的この宣言ですか?いくつかの友達に聞いてみましょう。 getSymbolは、異なるシンボルにそれが呼び出されるたびに返すのでs1s2二つの別々のプロパティスロットを作成するため

アリスは、はいを言います。 getSymbolはいつも、同じシンボルにs1それが呼び出されるたびに返し、s2が同じプロパティの宣言が競合しているため

ボブは、無言います。 getSymbolがランダムに二つの異なるシンボルの一つ返すので、誰が、何が起こっているか知っているので

イブは、ハハハ言います。

誰が正しいですか?何も思いつきません。誰もしない。我々はgetSymbolの実装を見ることができないので、ただ推測しているだけです。可能であれば、その実装は任意に複雑になる可能性があります。 getSymbol1たぶん

// Implementations not visible to us 
declare function getSymbol1(): Symbol; 
declare function getSymbol2(): Symbol; 

const s1 = getSymbol1(); 
const s2 = getSymbol2(); 

interface Type1 { 
    [s1]: string; 
    [s2]: number; 
} 

getSymbol2同じシンボルを返す:

また、我々はのgetSymbol振る舞いを記述できたとしても、我々はまだ、このコードを説明できません。多分彼らはしません。たぶん時々彼らはします。知るか?明確に個々のSymbol インスタンスにという名前を付ける方法がないと、解決できないパズルです。しかし、型システム、特に構造型システムは、インスタンスのアイデンティティを記述することにかなり悪いです。あなたはそれぞれのシンボルインスタンスに名前を付けるいくつかのシステムを持つことができますが、各呼び出しで新しいシンボルを返す関数を記述する方法が残っています。型システムは、2回呼び出された同じ関数が事実上同一である2つのオブジェクトを生成すると仮定しようとしているため、一般に、最初のスニペットのようなコードでは本当に苦労するでしょう。

+0

ありがとうございます!完璧な意味合いを持つ。 –

+0

しかし、おそらく、よく知られているhasInstanceのようなシンボルは、コンパイラに知られています。そして、私はそれが再割り当てされている場所で面白いビジネスは起こっていないと推測されます。 –

+0

正しい - 'Symbol'オブジェクトの宣言されたメンバは、その点で「通常」であるとみなされます –

関連する問題