Typescript: 提案：get/setアクセサーを異なるタイプにすることを許可する

私はこれがどのように素晴らしいかをここで見ることができます（そしてこれは私が今問題を見つけることができませんが以前に要求されました）が、ユーティリティがそれを保証するのに十分であるかどうかは不可能です。 問題は、アクセサが.d.tsで通常のプロパティと同じように表示されるため、通常のプロパティと同じように表示されないことです。 つまり、ゲッターとセッターの間に違いはないため、a）実装で単一のインスタンスメンバーではなくアクセサーを使用する必要があり、b）ゲッターとセッターのタイプの違いを指定する方法はありません。

ダン、迅速な返信ありがとうございます。 あまりエレガントではない方法に従います。 素晴らしい仕事をありがとう！

さまざまなタイプのJavaScriptゲッターとセッターは完全に有効であり、うまく機能します。これがこの機能の主な利点/目的であると思います。 TypeScriptがそれを台無しにするためだけにsetMyDate()を提供しなければならない。

このパターンに従う純粋なJSライブラリについても考えてください。.d.tsはユニオンまたはanyを公開する必要があります。

問題は、アクセサが通常のプロパティとは異なる方法で.d.tsに表示されないことです。

次に、この制限を修正し、この問題を未解決のままにしておく必要があります。

// MyClass.d.ts

// Instead of generating:
declare class MyClass {
  myDate: moment.Moment;
}

// Should generate:
declare class MyClass {
  get myDate(): moment.Moment;
  set myDate(value: Date | moment.Moment);
}

// Or shorter syntax:
declare class MyClass {
  myDate: (get: moment.Moment, set: Date | moment.Moment);
  // and 'fooBar: string' being a shorthand for 'fooBar: (get: string, set: string)'
}

これは単なる意見だと思いますが、 a.x = y; $の直後に$ a.x === yがtrueにならないようにセッターを書くことは、巨大な赤旗です。 そのような図書館の消費者は、どのプロパティに魔法の副作用があり、どれがそうでないかをどうやって知るのでしょうか？

どのプロパティに魔法の副作用があり、どのプロパティにないかをどうやって知るのですか？

JavaScriptでは直感的ではない可能性があり、TypeScriptではツール（IDE +コンパイラ）が文句を言います。 なぜTypeScriptが再び好きなのですか？ :)

さまざまなタイプのJavaScriptゲッターとセッターは完全に有効であり、うまく機能します。これがこの機能の主な利点/目的であると思います。

これは、JavaScriptは弱い型付けであるため、TypeScriptは弱い型付けである必要があると主張しています。 :-S

これは、JavaScriptは弱い型付けであるため、TypeScriptは弱い型付けである必要があると主張しています。

C＃はそれを許可し、それはこの言語を弱く型付けされたものにしませんC＃は異なる型のget/setを許可しません。

C＃はそれを許可し、それはこの言語を弱く型付けされたものにしませんC＃は異なる型のget/setを許可しません。

：ウィンク：

アクセサーは弱く型付けされるべきであると（私が見る限り）主張している人は誰もいません。彼らは、型を定義する柔軟性が必要であると主張しています。

多くの場合、プレーンな古いオブジェクトをオブジェクトインスタンスにコピーする必要があります。

    get fields(): Field[] {
      return this._fields;
    }

    set fields(value: any[]) {
      this._fields = value.map(Field.fromJson);
    }

これは他の方法よりもはるかに優れており、私のセッターは、目的のロジックセッターの正確なタイプをカプセル化できます。

@paulwalkerそこで使用するパターン（ anyを取るセッターとより具体的なタイプを返すゲッター）は今日有効です。

@danquirk知ってよかった、ありがとう！ ST用のIDEプラグインコンパイラを更新する必要があったようです。

@danquirkそれは遊び場（またはバージョン1.6.2）では機能しないようです：
http://www.typescriptlang.org/Playground#src =％0A％0Aclass％20Foo％20％7B％0A％0A％20％20get％20items（）％3A％20string％5B％5D％20％7B％0A ％09％20％20return％20％5B％5D％3B％0A％20％20％7D％0A％20％20％0A％20％20set％20items（value％3A％20any）％20％7B％0A％ 09％20％20％0A％20％20％7D％0A％7D

typescript @ next （バージョン1.8.0-dev.20151102）でテストしたところ、エラーが発生しました。

~$ tsc --version
message TS6029: Version 1.8.0-dev.20151102
~$ cat a.ts
class A {
    get something(): number {return 5;}
    set something(x: any) {}
}

~$ tsc -t es5 a.ts
a.ts(2,2): error TS2380: 'get' and 'set' accessor must have the same type.
a.ts(3,2): error TS2380: 'get' and 'set' accessor must have the same type.

皮肉なことに、Sublimeリンターを更新した後、TypeScript1.7.xを使用しているエラーがスローされなくなりました。 私はそれが1.7+で今後の拡張であると思っていたので、おそらく1.8.0は後退しました。

typescript1.7.5をサポートするバージョンのVisualStudioCode（0.10.5（2015年12月））を使用し、typescript 1.7.5をマシンにグローバルにインストールしても、これは依然として問題です。

では、これはどのバージョンでサポートされますか？
ありがとう

ダンは間違っていたと思います。 ゲッターとセッターは同じタイプである必要があります。

恥。 分度器テストで使用するページオブジェクトを作成する場合の優れた機能でした。

分度器テストを書くことができたでしょう：

po.email = "[email protected]";
expect(po.email).toBe("[email protected]");

...ページオブジェクトを作成することによって：

class PageObject {
    get email(): webdriver.promise.Promise<string> {
        return element(by.model("ctrl.user.email")).getAttribute("value")
    }
    set email(value: any) {
        element(by.model("ctrl.user.email")).clear().sendKeys(value);
    }
}

そのコードでは、セッターがanyタイプである必要がありますか？

ゲッターはwebdriver.promise.Promise<string>を返しますが、セッターはstringの値を割り当てます。

たぶん、次のより長い形式の分度器テストはそれをより明確にします：

po.email = "[email protected]";
var currentEmail : webdriver.promise.Promise<string> = po.email;
expect(currentEmail).toBe("[email protected]")

@RyanCavanaugh nullアノテーションの導入により、これにより、nullを指定してsetterを呼び出してデフォルト値に設定できるコードが防止されます。

class Style {
    private _width: number = 5;

    // `: number | null` encumbers callers with unnecessary `!`
    get width(): number {
        return this._width;
    }

    // `: number` prevents callers from passing in null
    set width(newWidth: number | null) {
        if (newWidth === null) {
            this._width = 5;
        }
        else {
            this._width = newWidth;
        }
    }
}

| nullと| undefinedが存在する場合に、少なくともタイプを異ならせることを検討できますか？

これは本当に素晴らしい機能です。

それで、これは機能になりますか？

@artyilは閉じられ、_By Design_のタグが付けられています。これは、現在、追加する予定がないことを示しています。 上記の懸念を無効にすると思われる説得力のあるユースケースがある場合は、自由にケースを作成できます。追加のフィードバックにより、コアチームは彼らの立場を再考する可能性があります。

@kitsonk上記のコメントでは、十分な数の説得力のあるユースケースが提供されていると思います。 現在の設計は、この制限のある他のほとんどの型付き言語の一般的なパターンに従いますが、Javascriptのコンテキストでは不要であり、過度に制限されています。 設計によるものですが、設計が間違っています。

同意します。

これについてもう少し考えた後。 ここでの問題は、実際には実装の複雑さだと思います。 個人的には@Arnavionの例は魅力的だと思いますが、今日の型システムはゲッター/セッターを通常のプロパティとして扱います。 これが機能するには、両方が同じ値である必要があります。 読み取り/書き込みタイプをサポートすることは大きな変更になるでしょう、私はここのユーティリティが実装コストの価値があるかどうかわかりません。

私はTypeScriptが大好きで、チームがそれに注いだすべての努力に感謝しています（本当に、皆さんは素晴らしいです！）が、私はこの決定に失望していることを認めなければなりません。 getFoo()/setFoo()またはget foo()/set foo()/setFooEx()の代替案よりもはるかに優れたソリューションになります。

問題のほんの短いリスト：

• 現在、プロパティには1つのタイプがあると想定しています。 ここで、すべての場所にあるすべてのプロパティの「読み取り」タイプと「書き込み」タイプを区別する必要があります。
• プロパティごとに1つではなく2つのタイプを推論する必要があるため、すべてのタイプの関係は大幅に複雑になります（ { get foo(): string | number; set foo(): boolean }は$＃ { foo: boolean | string | number } ＃$に割り当て可能ですか、またはその逆ですか？）
• 現在、プロパティは設定された後も、次の行に設定値のタイプがあると想定しています（これは、一部の人のコードベースでは明らかに間違った想定です、ワット？）。 おそらく、このようなプロパティのフロー制御分析を「オフ」にする必要があります。

正直なところ、私はここでコードの書き方について規範的になることを本当に控えようとしていますが、私はこのコードがこのコードであるという考えに本当に反対しています

foo.bar = "hello";
console.log(foo.bar);

正しいセマンティクスを持たせようとする言語で"hello"以外のものを印刷する必要があります。 プロパティは、フィールドと外部のオブザーバーを区別できない動作をする必要があります。

@RyanCavanaugh注入された意見についてあなたに同意しますが、私は_かもしれない_が非常にTypeScriptyであるという1つの反論を見ることができます...セッターで弱い型の何かを投げますが、常に強い型の何かを返すと、たとえば：

foo.bar = [ '1', 2 ];  // any[]
console.log(foo.bar);  // number[]: [ 1, 2 ]

個人的には、あなたがそんなに魔法のようになるのかと思う傾向がありますが、エンド開発者が曲がったり、折りたたまれたり、切断されたりすることを明確に理解できるように、メソッドを作成するのが最善です。

この機能の使用例は次のとおりです。 APIは、_Autocasting_という名前の機能を導入しました。 主な利点は、タイプが明確に定義されているプロパティを割り当てるためにインポートするクラスの数を排除できる、合理化された開発者エクスペリエンスです。

たとえば、colorプロパティは、 Colorインスタンスとして、またはrgba(r, g, b, a)のようなCSS文字列として、あるいは3つまたは4つの数値の配列として表現できます。 プロパティは、値を読み取るときに取得するタイプであるため、引き続きColorのインスタンスとして入力されます。

それに関するいくつかの情報： https ：//developers.arcgis.com/javascript/latest/guide/autocasting/index.html

ユーザーはこの機能を利用して、必要なインポートの数を減らし、割り当て後にタイプが行を変更することを完全に理解しています。

この問題の別の例： https ：//github.com/gulpjs/vinyl#filebase

file.base = 'd:\\dev';
console.log(file.base); //  'd:\\dev'
file.base = null;
console.log(file.base); //  'd:\\dev\\vinyl' (returns file.cwd)

したがって、セッターはstring | null | undefinedで、ゲッターはstringです。 このライブラリの型定義ではどの型を使用する必要がありますか？ 前者を使用する場合、コンパイラはどこでも役に立たないnullチェックを必要とします。後者を使用する場合、このプロパティにnullを割り当てることはできません。

getterがnullableを返すようにしたいが、setterが入力としてnullを許可してはならず、次のように定型化されている別の例があります。

class Memory {
    public location: string;
    public time: Date;
    public company: Person[];
}

class Person
{
    private _bestMemoryEver: Memory | null;

    public get bestMemoryEver(): Memory | null { // Might not have one yet
        return this._bestMemoryEver;
    }

    public set bestMemoryEver(memory: Memory) { // But when he/she gets one, it can only be replaced, not removed
        this._bestMemoryEver = memory;
    }
}

var someDude = new Person();
// ...
var bestMemory: Memory | null = someDude.bestMemoryEver;
//...
someDude.bestMemoryEver = null; // Oh no you don't!

ゲッター/セッターがnullで異なるようにするための特別なロジックを構築するのは大変な作業になる可能性があることを理解しています。それは私にとってそれほど大きな問題ではありませんが、持っていると便利です。

@ Elephant-Vessel哲学的に私はこの例が大好きです、それは人間の気まぐれな性質をよく表していますが、 null （またはundefined ）を許可することによってそれがさらに良く表されるとは確信していません）設定します。 システムのシナプス障害をモデル化するにはどうすればよいですか？

@aluanhaddadなぜシナプスの失敗が必要なのですか？ 私は私の宇宙にそのような悪いものを望んでいません;）

これに関する更新はありますか？ nullまたは未定義に設定されたときにデフォルト値を持つのはどうですか？

消費者が事前にnullチェックをしなくてはならないようにしたくありません。 現在、セッターを別のメソッドにする必要がありますが、同じものにしたいと思います。

以下は私が欲しいものです：

export class TestClass {
  private _prop?: number;

  get prop(): number {
    // return default value if not defined
    this._prop === undefined ? 0 : this._prop;
  }
  set prop(val: number | undefined) {
    this._prop = val;
  }
}

null以外のチェックの利点があることには落とし穴があるように思えますが、これはその1つです。 厳密なnullチェックをオフにすると、これは可能ですが、null参照の例外を防ぐためのコンパイラーのヘルプは得られません。 ただし、コンパイラの支援が必要な場合は、少なくともnull可能性に関して、ゲッターとセッターを別々に定義するなど、より多くのサポートが必要だと思います。

この問題のラベルは、それが設計上の制限であり、実装が複雑すぎると見なされることを示しています。つまり、誰かがこれが当てはまるという非常に説得力のある理由がある場合、それはどこにも行きません。

@mhegazy @kitsonk偏見があるかもしれませんが、これは、特にnullチェックがまだ行われていない言語のような他の中括弧で、一般的なパターンの厳密なnullチェックで発生したバグだと思います。 回避策では、コンシューマーがbang演算子を使用するか、実際にnullにならないことを確認する必要があります（これは、デフォルト値を使用してnullにならないという点です）。

厳密なnullチェックを追加すると、技術的に異なるタイプになるため、これは機能しなくなります。 強力な異なるタイプを設定するように求めているわけではありませんが、これを有効にするための設計要件によって、強力な異なるタイプも有効になるようです。

弱い型には別の設計を使用できます。たとえば、nullやundefinedなどの型は、完全に異なる型を有効にしたくない場合は、インターフェイス定義とd.tsファイルに特別な場合があります。

https://github.com/Microsoft/TypeScript/issues/2521#issuecomment-199650959への応答
実装がそれほど複雑ではない提案設計は次のとおりです。

export interface Test {
  undefset prop1: number; // property [get] type number and [set] type number | undefined
  nullset prop2: number; // property [get] type number and [set] type number | null
  nilset prop3: number; // property [get] type number and [set] type number | null | undefined
  undefget prop4: number; // property [get] type number | undefined and [set] type number
  nullget prop5: number; // property [get] type number | null and [set] type number
  nilget prop6: number; // property [get] type number | null | undefined and [set] type number
}

TypeScriptに精通しているこのスレッドを見ている人がいるようですので、まだ注意を払っている人が関連する質問に答えることができるかもしれません。 このCesiumの問題について、ここで説明しているget / setタイプの制限について説明しました。また、Cesiumの人々は、フォローしているパターンはC＃からのものであると言いました。これは暗黙のコンストラクターです。

TypeScriptは暗黙のコンストラクターをサポートできますか？ つまり、 myThing.fooは常にBar Barを直接割り当てることができますが、 numberを割り当てることもできます。開発者の便宜のために、静かに包まれて/ Barを初期化するために使用されますか？ Barに注釈を付けるか、「 numberはBar<number>に割り当て可能」と具体的に言うことでこれを行うことができる場合は、Cesiumの問題で説明されているユースケースに対応します。また、このスレッドで提起された問題の多く。

そうでない場合は、別の問題で暗黙のコンストラクターのサポートを提案する必要がありますか？

考えたり読んだりすればするほど、「暗黙のコンストラクターパターン」にはこの号で説明する機能が必要になると確信しています。 バニラJSで可能な唯一の方法は、オブジェクトのget / setアクセサーを使用することです。これは、名目上の割り当て（ =演算子）が実際にユーザー定義関数を呼び出すのはこのときだけだからです。 （そうですか？）だから、私たちは本当に必要になると思います

class MyThing{
  set foo(b: Bar<boolean> | boolean);
  get foo(): Bar<boolean>;
}

@RyanCavanaughが「正気のセマンティクス」ではないと考えているように聞こえます。

単純な事実は、このパターンを使用する非常に人気のあるJSライブラリがあり、既存のTS制約を考えると、説明するのは不可能ではないにしても難しいようです。 私が間違っているといいのですが。

JavaScriptは、あなたが記述したパターンをすでに許可しています。 _challenge_は、TypeScriptの型の読み取り側と書き込み側が、設計上、同じであると想定されていることです。 割り当てを禁止するように言語に変更が加えられました（ readonly ）が、_書き込みのみ_の概念を要求するいくつかの問題があり、現実世界の価値がほとんどないほど複雑であると議論されています。

IMO、JavaScriptがアクセサーを許可して以来、人々は潜在的にそれらと混同するAPIを作成してきました。 個人的には、割り当ての何かが_魔法のように_他の何かに変わるのは紛らわしいと思います。 暗黙的なもの、特に型変換は、JavaScriptIMOの悩みの種です。 問題を引き起こすのはまさに柔軟性です。 _magic_が存在するこれらのタイプの変換では、個人的にメソッドが呼び出されるのを見るのが好きです。ここでは、ある種の✨が発生し、値を取得するための読み取り専用ゲッターを作成することが、コンシューマーに対してもう少し明確になります。

これは、実際の使用法が存在しないことを意味するものではなく、それは潜在的に正気で論理的根拠です。 型システム全体を2つに分割することは複雑であると思います。この場合、型は読み取りと書き込みの条件で追跡する必要があります。 それは非常に重要なシナリオのようです。

ここで：sparkles：については同意しますが、パターンの使用に賛成または反対ではありません。すでに使用しているコードの背後に立ち、その形状を説明しようとしているだけです。 それはすでにそれが機能するように機能します、そしてTSは私にそれを説明するためのツールを与えていません。

良くも悪くも、JSは割り当てを関数呼び出しに変換する機能を提供しており、人々はそれを使用しています。 異なるタイプをset/getペアに割り当てる機能がないのに、なぜアンビエントタイピングにset/getがあるのでしょうか。 Salsaは、割り当てのどちら側にあるかに関係なく、常にmyThing.fooを単一タイプのメンバー変数として扱う場合、プロパティがゲッターとセッターで実装されていることを知る必要はありません。 （明らかに、実際のTypeScriptコンパイルはまったく別のものです。）

@ thw0rted

TypeScriptに精通しているこのスレッドを見ている人がいるようですので、まだ注意を払っている人が関連する質問に答えることができるかもしれません。 このCesiumの問題について、ここで説明しているget / setタイプの制限について説明しました。また、Cesiumの人々は、フォローしているパターンはC＃からのものであると言いました。これは暗黙のコンストラクターです。

C＃の暗黙的なユーザー定義の変換演算子は、値のタイプに基づいて静的コード生成を実行します。 TypeScriptタイプは消去され、実行時の動作には影響しません（$ Promiseポリフィラーのasync / awaitエッジケースは耐えられません）。

@kitsonk私はプロパティに関して一般的に反対しなければなりません。 Java、C ++、およびC＃でかなりの時間を費やしてきたので、プロパティ（C＃で見られるように）は重要な構文の抽象化を提供するため（これはJavaScriptでもある程度当てはまります）、絶対に大好きです。 これらにより、インターフェースは、構文を変更することなく、意味のある方法で読み取り/書き込み機能を分離できます。 Xを取得するときに、 getX()のような些細な操作で動詞が無駄になるのを見るのは嫌いです。
IMOの紛らわしいAPIは、アクセサを悪用すると言うようにその多くが、魔法のようなことをする_セッター_が多すぎることに起因しています。

読み取り専用であるが、一部のデータ（たとえば、 registry ）のライブビューがある場合、読み取り専用プロパティは非常に理解しやすいと思います。

interface Entry {key: string; value: any;}

export function createRegistry() {
  let entries: Entry[] = [];
  return {
    register(key: string, value: any) {
      entries = [...entries, {key, value}];
    },
    get entries() {
      return [...entries];
    }
  }
}

const registry = createRegistry();

registry.register('hello', '您好');
console.log(registry.entries); //[{key: 'hello', value: '您好'}]
registry.register('goodbye', '再见');
console.log(registry.entries); //[{key: 'hello', value: '您好'}, {key: 'goodbye', value: '再见'}]

接線で申し訳ありませんが、私はこれのアクセサーが大好きで、理解しやすいと思いますが、そうでなければ確信しており、読みやすさが私の最初の関心事です。

TypeScriptがJavaScriptを制限する場合、それは利点というよりも厄介なものになります。 TypeScriptは、開発者同士のコミュニケーションを支援するためのものではありませんか？

また、セッターは理由からミューテーターと呼ばれます。 変換が必要ない場合は、セッターを使用せず、自分で変数を設定します。

javascriptプロジェクトをtypescriptに移植します。 私はこの問題に遭遇しました。

これは、Angular @Inputデコレータで使用すると便利です。 値はテンプレートから渡されるため、私の意見では、さまざまな着信オブジェクトタイプを処理する方がはるかにクリーンになります。

更新：これは私にとってはうまくいくようです

import { Component, Input } from '@angular/core';
import { flatMap, isString, isArray, isFalsy } from 'lodash';

@Component({
  selector: 'app-error-notification',
  templateUrl: './error-notification.component.html',
})

export class ErrorNotificationComponent {
  private _errors: Array<string> = [];
  constructor() { }
  /**
   * 'errors' is expected to be an input of either a string or an array of strings
   */
  @Input() set errors(errors: Array<string> | any){
      // Caller just passed in a string instead of an array of strings
      if (isString(errors)) {
        this._errors = [errors];
      }
      // Caller passed in array, assuming it is a string array
      if (isArray(errors)) {
        this._errors = errors;
      }
      // Caller passed in something falsy, which means we should clear error list
      if (isFalsy(errors)) {
        this._errors = [];
      }
      // At this point just set it to whatever might have been passed in and let
      // the user debug when it is broken.
      this._errors = errors;
  }

  get errors() {
    return this._errors;
  }
}

それで、私たちはそうでしたか？ セッターとは違うタイプのゲッターを返す可能性を本当に持っていたいです。 例えば：

class Field {
  private _value: string;

  get value(): string {
    return this._value;
  }

  set value(value: any) {
    this._value = String(value);
  }
}

これは、ネイティブ実装の99％が行うことです（ (input as HTMLInputElement).valueに数値を渡すと、常に文字列が返されます。実際、getとsetはメソッドと見なされ、いくつかを許可する必要があります。

set value(value: string);
set value(value: number);
set value(value: any) {
  this._value = String(value);
}
  // AND/OR
set value(value: string | number) {
  this._value = String(value);
}

@raysuelzerは、コードが「機能する」と言った場合、 ErrorNotificationComponent.errorsはArray<string> | anyのタイプを返しませんか？ つまり、実際にArray<string>しか返されないことがわかっている場合は、使用するたびにタイプガードが必要になります。

@ lifaon74 、私が知る限り、この問題に関する動きはありません。 説得力のあるケースが作成されたと思います-複数のシナリオが提示され、これが原因でTypescriptで適切に記述できない大量のレガシーJSコード-しかし、問題は解決されました。 現場の事実が変わったと思ったら、新しいものを開いてみませんか？ 古い議論を読み直すというチームの方針はわかりませんが、私はあなたの背中を持っているでしょう。

古い議論を読み直すというチームの方針はわかりませんが、私はあなたの背中を持っているでしょう。

彼らは以前に閉じられた主題を再考します。 問題の上部に👍を提供することは、それが意味のあるものであるという信憑性をもたらします。 型システムはすべての読み取りと書き込みで分岐する必要があることを意味するため、一般的に「複雑すぎる」カテゴリに分類されると思います。その感覚は、それを入れて何を満足させるかという努力とコストだと思います。有効ですが、やや珍しいユースケースは価値がありません。

私の個人的な感想は、特にこのパターンを効果的に使用する既存のJavaScriptコードをモデル化できることは、_持っているといいことです_。

個人的には、レガシーJSの問題に対して、まったく面倒ではない回避策を考え出せば、問題は解決したと思います。 私はまだTSグリーンホーンのようなものなので、おそらく私の現在のソリューション（強制キャストまたは不要なタイプガード）は既存の機能の最適な使用ではありませんか？

同意。 タイプが同じでなければならない場合、 setterは非常に制限されます...強化してください。

これを達成するための推奨事項を探しています：

get price() {
    return (this._price as number);
  }

  set price(price) {
    this._price = typeof price === 'string' ? parseFloat(parseFloat(price).toFixed(8)) : parseFloat(price.toFixed(8));
  }

保存された値を数値にしたいのですが、文字列からセッターでfloatに変換したいので、プロパティを設定するたびにparseFloatを実行する必要はありません。

評決は、これが有効な（または少なくとも合理的に受け入れられている）Javascriptパターンであり、Typescriptの内部にうまく適合しないということだと思います。 内部の変更があまりにも大きな変更である場合、TSが内部でコンパイルする方法を変更するある種の注釈を取得できますか？ 何かのようなもの

class Widget {
  get price(): number | /** <strong i="7">@impossible</strong> */ string | undefined { return this._price; }
  set price(val: number|string|undefined){ ... }
}

let w = new Widget();
w.price = 10;
// Annotation processes as "let p:number|undefined = (w.price as number|undefined)"
let p: number|undefined = w.price;

言い換えると、TSがJSにトランスパイルされる前に、プリプロセッサ（？）がw.priceのすべての読み取りを明示的なキャストに変換するようにTSをマークアップできる可能性があります。 もちろん、TSがアノテーションを管理する方法の内部はわからないので、これは完全なゴミかもしれませんが、一般的な考え方は、TSトランスパイラーの方法を変更するよりも、TSを他のTSに魔法のように魔法をかける方が簡単かもしれないということですJSを生成します。

この機能は必要ないと言っているわけではありませんが、 setをバイパスする方法は次のとおりです。 IMO getは常に同じ変数タイプを返すはずなので、これで十分でした。

class Widget {
    get price(): number { return this._price; }
    set price(val){ return this.setPrice(val); } // call another function

    // do processing here
    private setPrice(price: number | string): number {
        let num = Number(price);
        return isNaN(num) ? 0 : num;
    }
}

@iamjoyce widget.price = '123'は、コードでコンパイルエラーを発行します

@iamjoyce =>コンパイラが$＃$ 1 $＃$でset price(val) val: numberを想定しているため、間違っています

ええ、私もここにいます。Angularのコンポーネントの使用法では、さまざまなゲッター/セッタータイプが必要なようです。

入力プロパティのタイプに関係なく、（バインディング式を使用しない限り）マークアップからコンポーネントプロパティを（属性を介して）設定すると、Angularは常に文字列を挿入します。 したがって、次のようにモデル化できると便利です。

private _someProperty: SomeEnum;
set someProperty(value: SomeEnum | string) {
   this._someProperty = this.coerceSomeEnum(value);
} 
get someProperty(): SomeEnum {
  return this._someProperty;
}

今日、これは| stringを省略した場合に機能しますが、それを使用すると、Angularがコンポーネントをどのように使用するかをより正確に説明できます。 その中で、コードからアクセスする場合、プロパティのタイプは重要ですが、属性のように設定すると、で文字列をブルートフォース攻撃します。

APIをこのように設計したいので、一般的にこの機能は必要ないと思います。 私は同意します、彼らが隠蔽の下で強制的な副作用を起こさないならば、特性はより良いです。 これを回避するには、属性セットとバインディングプロパティセットが異なるエントリポイントに入るようにAngularが設計されていれば素晴らしいと思います。

しかし、これを実際的に見ると、TypeScriptで、読み取り/書き込み型の同等性の公理に反するような方法で型を使用している外部ライブラリとの相互作用をモデル化できる場合に役立ちます。

この場合、あらゆる種類の迷惑なタイプのガード/アサーションが必要になるため、ゲッターで共用体タイプを使用することは非常に問題があります。 しかし、共用体型をセッターから外したままにしておくと、どのツールも、属性から設定されているプロパティが文字列から割り当て可能であることを確認しようとすることを決定する可能性があるため、間違っていると感じます。

したがって、この場合、型システムは、外部ライブラリが型を使用することを許可されている方法をキャプチャするのに十分な表現力がありません。 外部ライブラリは実際にはタイプ情報とともにタイプスクリプトレベルでこれらのタイプを消費しないため、これは_すぐに_重要ではありません。 しかし、ツールがタイプ情報を非常によく消費する可能性があるため、最終的には問題になる可能性があります。

上記の1人は、少し不快に思えますが、おそらく機能する可能性のある代替ソリューションについて言及しました。これにより、セッター/ゲッターの両方に共用体タイプを使用できますが、ユニオンの特定のタイプがゲッターには不可能であることを示す何らかの方法があります。 したがって、事実上、誰かがタイプガードを使用して存在しないことを確認したかのように、ゲッター呼び出しサイトのサイト制御フローでの考慮から事前に削除されます。 ただし、ゲッターのサブセットユニオンと比較して、セッターのスーパーセットユニオンを許可する場合と比較すると、これは煩わしいようです。

しかし、おそらくそれは内部的に物事を解決する方法です。 セッターがゲッタータイプの単なるスーパーセットユニオンである限り。 ゲッターとセッターのタイプを内部的に同等として扱いますが、ゲッターの共用体タイプの一部を不可能としてマークします。 そのため、制御フロー分析はそれらを考慮から除外します。 それは設計上の制約を回避しますか？

上記について詳しく説明します。 複合型の一部を不可能と表現できることは、型表現の観点からは便利なことかもしれません。 これは、同じ構造を持つが不可能な修飾子がない別のタイプとの同等性に影響を与えません。 不可能な修飾子は、制御フロー分析にのみ影響します。

別の提案として、ユーザー定義の型ガードを戻り値に適用する構文がある場合は、これでも十分です。 これは通常の状況では少しばかげていることを理解していますが、戻り値と引数にそのような表現力があると、これらのエッジケースを解決するのに役立ちます。

戻り値に対するユーザー定義の型ガードには、プロパティに押しつぶされたときに型宣言/インターフェイスで表現できるものであるという利点もありますか？

ここに別のユースケースを追加するだけで、mobx-state-treeはいくつかの異なる方法（インスタンスとスナップショットタイプから）でプロパティを設定できますが、getアクセサーから単一の標準的な方法（インスタンス）でのみプロパティを返します。したがって、これがサポートされていれば非常に便利です。

私はこのように回避しています：

interface SomeNestedString {
  foo: string;
}

...

private _foo: SomeNestedString | string;

get foo(): SomeNestedString | string {
  return this._foo;
}

set foo(value: SomeNestedString | string) {
  this._foo = (value as SomeNestedString).foo;
}

私はそれが目前の問題を回避するとは思わない。 実際には、getterは共用体型のサブセットしか返さないにもかかわらず、getterを使用するときは、型ガードが必要です。

TSLintを回避するためにanyを使用しています。 そして、コンパイラも文句を言いません。

export class FooBar {
  private bar: string;

  get foo (): string | any {
    return this.bar;
  }

  set foo (value: Date | string | any) {
    // Type guarding enables IntelliSense in VS Code
    if (value instanceof Date) {
      this.bar = value.toISOString();
    } else if (typeof value === 'string') {
      this.bar = value;
    } else {
      this.bar = String(value); // Or throw an error
    }
  }
}

@jpidelatorreこのようにすると、型の安全性が失われます。

const fooBar = new FooBar()
const a: number = fooBar.foo // works while it should fail
fooBar.foo = 123 // fails only at runtime, not compile time. It doesnt fail in this particular case with strings and numbers, but it will with something more complex

@keenondrumsだからこそ、アクセサーにさまざまなタイプを持たせたいのです。 私が見つけたのは回避策であり、解決策ではありません。

@jpidelatorre私の現在の回避策は、セッターとして別の関数を使用することです

export class FooBar {
  private bar: string;

  get foo (): string {
    return this.bar;
  }

  setFoo (value: Date | string ) {}
}

@keenondrumsアクセサーほど見栄えは良くありませんが、これまでで最高のオプションです。

ゲッターに別の関数を使用しない限り、Angularコンポーネントの@inputプロパティで何が起こるかについてのモデルではありません。

これはあまりにも醜いです。

この機能も必要ですが、回避策がない.d.tsファイルで正常に機能する必要があります。 Mocha（Objective-C / Javascriptブリッジ）を介して公開されたいくつかのクラスを文書化しようとしていますが、ラップされたアイテムのインスタンスプロパティは次のように設定されています。

class Foo {
    get bar:()=>number;
    set bar:number;
}

const foo = new Foo();
foo.bar = 3;
foo.bar(); // 3

また、APIを使用すると、インターフェイスに一致するオブジェクトを使用してプロパティを設定できるが、ゲッターは常に実際のクラスインスタンスを返す場合が多くあります。

interface IFoo {
    bar: string;
}

class Foo implements IFoo {
    bar: string;
    toString():string;
}

class Example {
    get foo:Foo;
    set foo:Foo|IFoo;
}

この問題をほとんど忘れていたのですが、読み返してみると思い浮かびました。 これは抽象的に行う価値があるが、技術的に複雑すぎて実現できないという考えに落ち着いたと思います。 これはトレードオフの計算です。技術的に不可能ではありません。実装するのに時間と労力（および追加のコードの複雑さ）をかけるだけの価値はありません。 右？

これにより、コアDOM APIを正確に記述できなくなるという事実は、数学をまったく変えませんか？ @RyanCavanaughは言う

私は、このコードfoo.bar = "hello"; console.log(foo.bar);が、正しいセマンティクスを持たせようとする言語で「hello」以外のものを出力する必要があるという考えに本当に反対します。

このように使用する必要があるかどうかについては議論の余地がありますが、DOMは常にel.hidden=1; console.log(el.hidden) // <-- true, not 1のような構造をサポートしてきました。 これは、少数の人々が使用する単なるパターンではなく、人気のあるライブラリにあるというだけではないので、それをサポートすることをお勧めします。 これは、JSが常に機能してきた方法の中心的な信条であり、言語の魂に少しDWIMが組み込まれています。言語レベルでそれを不可能にすることは、TSの基本原則を破り、JSの「スーパーセット」でなければなりません。 。 ベン図から突き出た醜い泡であり、忘れてはなりません。

これが、セッター/ゲッターを同じタイプに保つというアイデアが今でも好きな理由です。

number | boolean

しかし、ある種のtypegaurdを導入すると、ゲッターは技術的には同じ共用体型を持ちますが、実際には、和集合内の型のサブセットしか返さないことを示すことができます。 それをゲッターのある種のナローイングガード（推論フローのもの）として扱うことは、タイプモデルへの変更よりも簡単になりませんか？ （彼は内部について何も知らないと言います...）

あるいは、ゲッターで使用されるタイプがセッタータイプの厳密なサブセットである場合、これは単に暗示される可能性がありますか？

あるいは、ゲッターで使用されるタイプがセッタータイプの厳密なサブセットである場合、これは単に暗示される可能性がありますか？

👍！

設定できないタイプを取得することはできないはずだということには、私たち全員が同意できると思います。 getのタイプを、常にそうなることがわかっているタイプに自動的に絞り込む方法が欲しいのですが。

型安全性などすべてに違反することに反対する人がいる理由がわかりません。 少なくともセッターに異なるタイプを許可しても、タイプの安全性に違反することはないと思います。他のタイプをプロパティに設定することを許可しないチェックをどのように行っているかです。
元：
配列としてプロパティを持っているとしましょうただし、DBからは、「10,20,40」のようにコンマで区切った文字列として返されます。 しかし、今はそれをmodeプロパティにマップできないので、次のように許可できれば非常に役立ちます。

private _employeeIdList：number []

get EmployeeIDList（）：number [] {
this._employeeIdListを返します;
}
set EmployeeIDList（_idList： any ）{
if（typeof _idList =='string'）{
this._employeeIdList = _idList.split（'、'）。map（d => Number（d））;
}
else if（typeof _idList =='object'）{
this._employeeIdList = _idList as number [];
}
}

私はこの問題を簡単に解決でき、SETで別のタイプを許可しても完全にタイプセーフですが、それでもプロパティに間違ったタイプを割り当てることはできません。 だから勝つ勝つ。 チームメンバーが自分のエゴを捨てて、それが生み出す問題を考え、これを修正しようとすることを願っています。

これは、既存のJSライブラリの動作をモデル化するために非常に重要であると私はまだ考えているという点でチャイムを鳴らしたいと思います。

ノーズを上げて、タイプを着信タイプのサブセットに強制し、常にそのサブセットをコードの臭いとしてゲッターに返すセッターを定義することはすべてうまくいきますが、実際には、これはJSランドでかなり一般的なパターンです。

TypeScriptは、理想的に構造化されたAPIがなくても、既存のJSAPIのキャガリーを説明するときに非常に表現力豊かになるという点で素晴らしいと思います。 これは、TypeScriptが、ゲッターがゲッターのタイプの厳密なサブセットであるタイプを常に返すことを示すのに十分な表現力がある場合、既存のAPIのモデリングに多大な価値を追加するシーンだと思います。 DOM！

信頼できるタイプは、DOMXSSと戦うための新しいブラウザーAPIの提案です。 Chromium（フラグの後ろ）にすでに実装されています。 APIの大部分は、信頼できるタイプを受け入れるようにさまざまなDOMプロパティのセッターを変更します。 たとえば、 .innerHTMLはTrustedHTML | string $を受け入れますが、常にstringを返します。 TypeScriptでAPIを説明するには、この問題を修正する必要があります。

前のコメントとの違いは、これはブラウザAPI（ユーザーランドライブラリではない）であり、簡単に変更できないことです。 また、 Element.innerHTML any （現在可能な唯一のソリューション）に変更した場合の影響は、ユーザーランドライブラリを不正確に記述するよりも大きくなります。

このプルリクエストが再開される可能性はありますか？ または私が逃した他の解決策はありますか？

Cc： @mprobst 、@koto。

TypeScriptなどの型共用体をサポートする言語では、この機能は自然であり、セールスポイントです。

@RyanCavanaughゲッターとセッターが同じタイプの場合でも、セッターが値を保存する前にサニタイズを行う可能性があるため、 o.x = y $の後に$ o.x === yが保証されるわけではありません。

element.scrollTop = -100;
element.scrollTop; // returns 0

私は@vranaによる懸念を2番目にしています。 現在の動作では、Typescriptで既存のAPIの一部をモデル化することは不可能です。

これは、セッターとゲッターのタイプが異なる多くのWebAPIに特に当てはまります。 実際には、Web APIセッターはあらゆる種類の型強制を実行します。それらの一部は特定のブラウザー機能に対して直接指定されますが、ほとんどはIDLを介して暗黙的に指定されます。 多くのセッターも値を変更します。たとえば、ロケーションインターフェイスの仕様を参照してください。 これは単一の開発者の間違いではありません-それはWeb開発者がコーディングするAPIの仕様です。

ゲッタータイプを絞り込むと、TypescriptがそれらのAPIを表すことができますが、これは現在不可能です。

プロパティのタイプは、セッターに提供したり、ゲッターから取得したりできる可能なタイプの和集合であると言うのが正しいため、これらのAPIを表すことができます。

APIをそのように説明することは_効率的_ではありません。 消費者は、ゲッターを使用して可能なタイプを絞り込むすべてのインスタンスでタイプガードを使用する必要があります。

多くのWebAPIは仕様に固定されているため、ゲッターから常にナローされた型を返すことを公理的にしていなくても問題ありません。

しかし、それを少し脇に置いて、ユーザーAPIについて話す場合でも、セッターで共用体型を受け入れるための強力なユースケースは「スクリプト」です。 私たちは、実際に必要なタイプに受け入れられるように強制できる一連の離散タイプを受け入れたいと考えています。

なぜそれを許可するのですか？ 使いやすさ。

これは、自分のチームが使用するために社内で開発しているAPIにとっては重要ではないかもしれませんが、一般的な一般消費向けに設計されたAPIにとっては非常に重要です。

TypeScriptを使用すると、一部のプロパティで受け入れ可能な型を緩和したAPIを正確に記述できるのはすばらしいことですが、その利点は、ゲッターの戻り型を判別するために過度の型チェック/保護が必要なもう一方の端の摩擦によって損なわれます。 、これは_specify_することをお勧めします。

これは、 @RyanCavanaughが主張する理想的なケースとは異なるシナリオだと思います。 この場合、バッキングフィールドも同じ共用体タイプであるため、ゲッターとセッターは常に同じ共用体タイプである必要があり、常にその値をラウンドトリップし、そのタイプを変更することは無意味です。

ケースは、より理想的な共用体型の使用法に集中していると思います。これにより、構築された型を処理し、実際にはその共用体型をセマンティック単位として扱います。これは、おそらくエイリアスを作成する必要があります。

type urlRep = string | Url;

ほとんどのものはそれを往復するだけで、一般的な小道具だけを扱います、そしてある場合にはあなたはいくつかのタイプの警備員でブラックボックスを壊します。

これは、ここで説明しているシナリオとはまったく異なるシナリオだと思います。 私たちが説明しているのは、特にJavaScriptのようなスクリプト言語で使用するための一般/パブリック使用API​​は、理想的なタイプに強制することに同意するタイプの範囲があるため、セッターの受け入れ可能なタイプを意図的に緩和することが多いという現実です。彼らはそれらすべてを受け入れるための生活の質の改善としてそれを提供します。

この種のことは、APIのプロデューサーとコンシューマーの両方である場合、より多くの作業を必要とするため、無意味に見えるかもしれませんが、大量消費用のAPIを設計している場合は非常に理にかなっています。

そして、私は、セッター/ゲッターが_disjoint_タイプを持つことを誰も望んでいないと思います。 ここで説明しているのは、APIプロデューサーがAPIコンシューマーに対して、ゲッターがセッターの共用体型の厳密なサブセットである型の値を返すことを表明することです。

そして、セッター/ゲッターが互いに素なタイプを持つことを誰も望んでいないと思います。

それに対抗する視点を提供するためだけに。 setter / getterに互いに素な型を使用することは、javascriptでは完全に合法であるため、私は間違いなくそれを望んでいます。 そして、私は、主な目標は、JavaScriptで合法であるもの（少なくとも.d.tsレベルで）を正しく入力するのに十分な表現力のある型システムにすることであるべきだと思います。 それは良い習慣ではないことを理解しています。たとえば、グローバルオブジェクトや、関数などの組み込みのプロトタイプを変更することもできませんが、.d.tsファイルに問題なく入力することはできますが、それを後悔している人は誰もいません。私たちはそれを行うことができます（それはいくつかの不十分に設計された型定義ファイルを確実に型付けされたものに表示させますが）。

私が制御できない正しいタイプを使用するために、これを機能にする必要がある状況に遭遇しました。 セッターは、よりリベラルで、ゲッターが一貫して返すことができるより保守的なタイプに強制する必要があります。

この機能があったらいいのにと思います。 JavaScriptコードをTypeScriptに移植していますが、型の安全性が必要な場合は、セッターをリファクタリングする必要があるのは非常に残念です。

たとえば、私は次のようなものを持っています：

class Vector3 { /* ... */ }

type XYZ = Vector3 | [number, number, number] | {x: number, y: number, z: number}
type PropertyAnimator = (x: number, y: number, z: number, timestamp: number) => XYZ
type XYZSettables =  XYZ | PropertyAnimator

export class Transformable {
        // ...

        set position(newValue: XYZSettables) {
            this._setPropertyXYZ('position', newValue)
        }
        get position(): Vector3 {
            return this._props.position
        }

        // ...
}

ご想像のとおり、使用法は非常に柔軟です。

const transform = new Transformable

// use an array
transform.position = [20, 30, 40]

// use an object
transform.position = {y: 30, z: 40} // skip `x` this time

// animate manually, a property directly
requestAnimationFrame((time) => {
  transform.position.x = 100 * Math.sin(time * 0.001)
})

// animate manually, with an array, which could be shared across instances
const pos = [10, 20, 30]
requestAnimationFrame((time) => {
  pos[2] = 100 * Math.sin(time * 0.001)
  transform.position = pos
})

// Animate with a property function
transform.position = (x, y, z, time) => [x, y, 100 * Math.sin(time * 0.001)]

// or a simple increment:
transform.position = (x, y, z) => [x, y, ++z]

// etc

// etc

// etc

これは4歳です。 どうしてまだ修正されていないのですか？ 上記のコメントで述べたように、この機能は重要です！ 少なくとも問題を再開することを検討しますか？

そして私は@kitsonkに完全に同意します：

@kitsonk上記のコメントでは、十分な数の説得力のあるユースケースが提供されていると思います。 現在の設計は、この制限のある他のほとんどの型付き言語の一般的なパターンに従いますが、Javascriptのコンテキストでは不要であり、過度に制限されています。 設計によるものですが、設計が間違っています。

TypeScript 3.6では、宣言ファイルにアクセサーを入力するための構文が導入されましたが、ゲッターとセッターのタイプは同じでなければならないという制限があります。

私たちのUIツールキットは自動キャストセッターに大きく依存しており、セッターはゲッターによって返される特異なタイプよりも多くのタイプを受け入れます。 したがって、TSがこのパターンをタイプセーフにする方法を提供してくれれば素晴らしいと思います。

@RyanCavanaughが3年前にこの機能の最も具体的な反論をしたようです。 最近報告されたDOMのユースケースと、新しい宣言構文の可用性により、新しい決定が可能になるのではないかと思います。

はい、その新機能を見てすぐに、この機能のリクエストについても考えました。 UIフレームワークの目的にも必要です。 これは実際のユースケースです。

TSConf 2019は10月11日に開催されます。誰かがチャンスをつかめば、これはQ＆Aセッションの素晴らしい振り返りになると思います🤔

私はこの長いスレッドでこれを前に言ったかもしれませんが、それは繰り返しに耐えると思います。

TypeScriptの表現型システムであるIMOは、2つの別個の目的を果たします。 1つ目は、より安全な新しいコードを記述できるようにすることです。 そして、それが唯一の目的である場合は、このシナリオを許可しない場合はコードの方が安全である可能性があるため、このユースケースを回避できるという議論を行うことができます（ただし、これについてはまだ議論できると思います）。

ただし、2番目の目的は、ライブラリの動作をそのままキャプチャすることであり、DOMおよびJSライブラリでは、セッターで自動強制し、ゲッターで1つの予期される型を返すのがかなり一般的な方法です。 これを型システムでキャプチャできるようにすることで、既存のフレームワークをより正確に記述できるようになります。

少なくとも、ここでDesign Limitationを削除できると思いますが、それはもう関係ないと思います。

これにより、プロキシの実行も非常に困難になります。
https://stackoverflow.com/questions/57948140/typescript-proxy-which-returns-a-different-type-from-get-than-it-takes-for-set

これは明らかに、＃33749ごとに.style.display = ...something nullable...がタイプチェックを行わなくなった理由です。 これは、nullablityの正しさの問題として提示されます。 それは少し不誠実ですよね？ バグ修正として誤ったラベルが付けられている場合、新しい重大な変更を把握する必要があるのは面倒です（これが原因である可能性のある実際の問題を探しに行きました）。 個人的には、 nullが「デフォルトを使用」という特別な動作をすることは、空の文字列よりもはるかに驚くことではありません。 そしてtypescipt3.7までは、それをキャプチャするためにnullを使用することを好みました。 いずれにせよ、この制限を回避するために意図的に誤った型注釈がそのように明確にラベル付けされていれば、アップグレードの問題のトリアージ時間を節約できると便利です。

私はまた、これへの道を見つけることに興味があります。 アンビエントコンテキストでのみ許可された場合はどうなりますか？ @RyanCavanaughは、複雑さの懸念に対処するのに役立ちますか？

これの私のユースケースは、プロキシがpromiseを返すAPIを持っていますが、set操作はpromiseを設定しません。 現在、TypeScriptでこれを説明することはできません。

let post = await loadPost()
let user = await loadUser()
post.author = user // Proxy handles links these two objects via remote IDs
await save(post)

// Somewhere else in code
let post = await loadPost()
let author = await post.author

タイプを修正するネイティブ関数であろうと、一般的なプロキシであろうと、TypeScriptは、それらのタイプの機能が間違いであったというスタンスのようです。

彼らは本当にこのリストから＃6と＃7を削除する必要があります（https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals#goals）

私の問題

setメソッドの配列にアイテムをプッシュし、getメソッドで配列全体を取得したいと思います。 今のところ、正常に機能するset myArray(...value: string[])を使用する必要があります。 この問題に多くの問題を抱えています...これを削除することを検討してください。 情報や警告はこれに問題なく機能します。

例（やりたいこと）

class MyClass {
   _myArray: string[] = [];

   set myArray(value: string) {
      this._myArray.push(value);
   }

   get myArray(): string[] {
      return this._myArray;
   }
}

例（私がしなければならないこと）

class MyClass {
   _myArray: string[] = [];

   set myArray(...value: string[]) {
      this._myArray.push(value[0]);
   }

   get myArray(): string[] {
      return this._myArray;
   }
}

これが必要になったときに思いついた解決策の1つは、プロパティをunion typeに設定することでした。 これは、私の時間がAPIから文字列として入力されるためですが、UIのモーメントオブジェクトとして設定する必要があります。

私の例

class TimeStorage {
    _startDate: string | Moment = ""
    _endDate: string | Moment = ""

    set startDate(date: Moment | string) {
        this._startDate = moment(date).utc()
    }
    get startDate(): Moment | string {
        return moment.utc(this._startDate)
    }

    set endDate(date: Moment) { 
        this._endDate = moment.utc(date)
    }
    get endDate() { 
        return moment.utc(this._endDate)
    }
}

私はパーティーに少し遅れていますが、最近この問題に自分で遭遇しました。 それは興味深いジレンマなので、少しいじりました。

これが私たちが作りたいものであると仮定しましょう。文字列と数値を（目的を問わず）受け入れるプロパティを持つ単純なクラスですが、プロパティは実際には文字列として格納されます。

class Foo {
    constructor() {
        this._bar = '';
        this.baz = '';
    }

    // error: 'get' and 'set' accessor must have the same type.(2380)
    get bar(): string {
        return this._bar;
    }

    // error: 'get' and 'set' accessor must have the same type.(2380)
    set bar(value: string | number) {
        this._bar = value.toString();
    }

    public baz: string;
    private _bar: string;
}

これは不可能であり、強い型付けが必要なため、追加のコードが必要です。 ここで、この例の目的のために、誰かが次のようなプロパティライブラリを作成したとしましょう。

/**
 * Abstract base class for properties.
 */
abstract class Property<GetType, SetType> {
    abstract get(): GetType;
    abstract set(value: SetType): void;
}

/**
 * Proxify an object so that it's get and set accessors are proxied to
 * the corresponding Property `get` and `set` calls.
 */
function proxify<T extends object>(obj: T) {
    return new Proxy<any>(obj, {
        get(target, key) {
            const prop = target[key];
            return (prop instanceof Property) ? prop.get() : prop;
        },
        set(target, key, value) {
            const prop = target[key];
            if (prop instanceof Property) {
                prop.set(value);
            } else {
                target[key] = value;
            }
            return true;
        }
    });
}

このライブラリを使用すると、次のようにクラスの型付きプロパティを実装できます。

class Bar extends Property<string, string | number> {
    constructor(bar: string | number) {
        super();
        this.set(bar);
    }

    get(): string {
        return this._bar;
    }

    set(value: string | number) {
        this._bar = value.toString();
    }

    private _bar: string;
}

class Foo {
    constructor() {
        this.bar = new Bar('');
        this.baz = '';
    }

    public bar: Bar;
    public baz: string;
}

そして、このクラスを使用すると、タイプセーフなゲッターとセッターがbarなります。

const foo = new Foo();

// use property's typed setter
foo.bar.set(42);
foo.baz = 'foobar';

// use property's typed getter
// output: 42 foobar
console.log(foo.bar.get(), foo.baz);

また、プロパティセッターまたはゲッターをより動的に使用する必要がある場合は、 proxify関数を使用してそれをラップできます。

const foo = new Foo();

// use proxified property setters
Object.assign(proxify(foo), { bar: 100, baz: 'hello world' });

// use property's typed getter
// output: 100 hello world
console.log(foo.bar.get(), foo.baz);

// use proxified property getters
// output: {"bar":"100","baz":"hello world"}
console.log(JSON.stringify(proxify(foo)));

免責事項：誰かがこのコードを取得してライブラリに入れたい場合、または彼/彼女が望むことを何でもしたい場合は、遠慮なくそうしてください。 私は怠け者です。

ほんの少しの追加のメモ、そして私はこの長いリストの人々にスパムを送るのをやめることを約束します！

これを架空のライブラリに追加すると、次のようになります。

/**
 * Create a property with custom `get` and `set` accessors.
 */
function property<GetType, SetType>(property: {
    get: () => GetType,
    set: (value: SetType) => void
}) {
    const obj = { ...property };
    Object.setPrototypeOf(obj, Property.prototype);
    return obj;
}

元のクラスに少し近い実装を取得し、最も重要なのはthisにアクセスできることです。

class Foo {
    constructor() {
        this._bar = '';
        this.baz = '';
    }

    public bar = property({
        get: (): string => {
            return this._bar;
        },
        set: (value: string | number) => {
            this._bar = value.toString();
        }
    });

    public baz: string;
    private _bar: string;
}

それは世界で最も美しいものではありませんが、機能します。 たぶん誰かがこれを洗練して実際に素晴らしいものを作ることができます。

万が一、このスレッドを読んでいる個人がこの機能が重要であると確信していない場合は、Angularが導入したばかりのこの信じられないほど醜いハックを紹介します。

ここで値のタイプをブール値からブール値|''に変更して、セッターが実際に受け入れる値のセットと一致させることが理想的です。 TypeScriptでは、getterとsetterの両方が同じ型である必要があるため、getterがブール値を返す必要がある場合、setterはより狭い型でスタックします。Angularは、@ Input（）のより広くより許容的な型のチェックをサポートします。入力フィールド自体に対して宣言されています。 これを有効にするには、ngAcceptInputType_プレフィックスが付いた静的プロパティをコンポーネントクラスに追加します。

`` ``
クラスSubmitButton{
private _disabled：boolean;

disable（）を取得します：boolean {
this._disabledを返します。
}

set disable（value：boolean）{
this._disabled =（value ===''）|| 価値;
}

static ngAcceptInputType_disabled：boolean |'';
}
`` ``

これを修正してください。

うん、Angularが使用したいパターンをサポートするために、文字通りあちこちにこの醜さがあります。 現在の制限はあまりにも意見が分かれています。

TSを使用して、Webランドのライブラリ全体をモデル化する場合は、意見を少なくするように努力する必要があります。そうしないと、すべてのデザインをモデル化できなくなります。

この時点で、この問題が再開されない理由を伝える責任は寄稿者にあると思いますか？ この時点でこれにさらに強く反対している貢献メンバーはいますか？

W3C仕様に一致するNodeJ用のDOMライブラリを構築していますが、このTypescriptの問題により不可能になっています。 すべてのアップデート？

TypeScriptのコアチーム内の一部が、地球上で最も使用されているJavaScriptライブラリの1つであるDOMを再作成するために必要な機能に反対していることは、私にとって衝撃的です。

a）W3C DOM仕様の多くの部分を実装し、b）TypeScriptの型システムを使用する方法は他にありません（TypeScriptの目的全体を無効にするanyをいたるところに使用する場合を除きます）。

typescriptlang.orgのホームページは、次のように記載されている場合、現在不正確です。

TypeScriptは、プレーンJavaScriptにコンパイルされるJavaScriptの型付きスーパーセットです。

JavaScriptのDOM仕様を再作成できないことは、TypeScriptが依然としてJavascriptのサブセットであり、スーパーセットではないことを示しています。

この機能の実装に関して、私は@ gmurray81と、ゲッターの型はセッターの共用体型のサブセットでなければならないと主張した他の多くの人に同意します。 これにより、タイピングがばらばらになることはありません。 このアプローチにより、セッターの関数は、ゲッターのタイプを破壊することなく入力をクリーンアップできます（つまり、 anyの使用に頼らざるを得なくなります）。

これが私にはできないことです。 JSでも同様のことをしましたが、TSではできません。

本当に実装できる4年間の問題。

export const enum Conns {
  none = 0, d = 1, u = 2, ud = 3,
  r = 4, rd = 5, ru = 6, rud = 7,
  l = 8, ld = 9, lu = 10, lud = 11,
  lr = 12, lrd = 13, lru = 14, lrud = 15,
  total = 16
}

class  Tile {
  public connections = Conns.none;

  get connLeft() { return this.connections & Conns.l; };

  set connLeft(val: boolean) { this.connections = val ? (this.connections | Conns.l) : (this.connections & ~Conns.l); }
}

今この問題に遭遇しています。 @calebjclarkを引用すると、以下は賢明な解決策のようです。

この機能の実装に関して、私は@ gmurray81と、ゲッターの型はセッターの共用体型のサブセットでなければならないと主張した他の多くの人に同意します。 これにより、タイピングがばらばらになることはありません。 このアプローチにより、セッターの関数は、ゲッターのタイプを破壊することなく（つまり、いずれかを使用するように強制されることなく）入力をクリーンアップできます。

セッターのタイプのサブセットであるゲッターの場合、それは不必要に制限されていると思います。 実際、実装が常にゲッターのタイプのサブタイプを返す限り、セッターのタイプは理論的には文字通り何でもかまいません。 セッターがゲッターのタイプのスーパータイプであることを要求することは、このチケットで提示されたいくつかのユースケースを満たすかもしれない奇妙な制限のようなものですが、後で確実に苦情を受けるでしょう。

そうは言っても、クラスは暗黙的にインターフェースでもあり、ゲッターとセッターは本質的にインターフェースには表示されない実装の詳細です。 OPの例では、最終的にtype MyClass = { myDate(): moment.Moment; }なります。 これらの新しいゲッターとセッターのタイプをインターフェースの一部として公開する必要がありますが、それが望ましい理由は個人的にはわかりません。

この問題は基本的に、 =と===の演算子のオーバーロードの制限の少ないバージョンを求めています。 （ゲッターとセッターはすでに演算子のオーバーロードです。）そして、他の言語で演算子のオーバーロードを扱ったことがある人として、私はそれらがほとんどの場合避けられるべきだと感じていると言います。 確かに、誰かがデカルト点や極点などの数学的な例を提案する可能性がありますが、TSを使用するほとんどの場合（このスレッドの例を含む）、演算子のオーバーロードが必要なのはおそらくコードの臭いであると私は主張します。 APIが単純になっているように見えるかもしれませんが、逆の傾向があります。 先に述べたように、次のことが必ずしも真実ではないということは、非常に混乱し、直感的ではありません。

foo.x = y;
if (foo.x === y) { // this could be false?

（セッターが使用されているのを見て合理的と思われるのは、ログ記録と、フィールドが変更されたかどうかを他の人が判断できるようにオブジェクトに「ダーティ」フラグを設定するためだけだと思います。どちらも実際には契約を変更しません。物体。）

@MikeyBurkman

[...]しかし、TSを使用するほとんどの場合（このスレッドの例を含む）、演算子のオーバーロードが必要なのはおそらくコードの臭いであると私は主張します[...]

 foo.x = y; 
 if (foo.x === y) { // this could be false?

したがって、型を一致させるだけでは驚くべき動作を防ぐことはできません。実際、 el.style.display = ''; //so is this now true: el.style.display === ''?は、それが理論的でもないことを示しています。 ちなみに、昔ながらのフィールドでも、NaNの仮定は当てはまりません。

しかし、もっと重要なことは、TSは、DOMのようなメジャーで変更される可能性が低いものを含め、既存のJS APIと相互運用する必要があるため、TSがこれらのことについて実際に意見を述べることができないという点を無視していることです。 そのため、APIが理想的であるかどうかは問題ではありません。 重要なのは、TSがそのような特定のAPIときれいに相互運用できないことです。 これで、APIが内部で使用したフォールバックロジックを再実装して、セッターに渡されたゲッタータイプ外の値を強制し、プロパティをゲッタータイプとして入力するか、タイプチェックを無視して追加する必要があります。各ゲッターサイトでの役に立たないタイプアサーション、したがって、セッタータイプとしてプロパティを入力します。 または、さらに悪いことに、それが理想的であるかどうかに関係なく、TSがDOMに注釈を付けるためにたまたま選択したことは何でもします。

それらの選択はすべて悪いです。 これを回避する唯一の方法は、JS apiを可能な限り忠実に表現する必要性を受け入れることです。ここでは、それが可能であるように思われます（確かに、これを明らかに重要にする可能性のあるTS内部の知識がなくても）。

それは可能だと思われます（確かに、これを明らかに重要にする可能性のあるTS内部の知識がなくても）

彼らが最近有効にした新しい型宣言構文のいくつかは、以前は実現不可能だったときにこれを表現可能にする可能性があると思うので、この問題を再開することを本当に検討する必要があります... @ RyanCavanaugh

理想的な世界では、TSはすべてのJSAPIと相互運用します。 しかし、そうではありません。 TSで正しく入力できないJSイディオムがたくさんあります。 しかし、私はむしろ彼らが実際に悪いことではなく、より良いプログラミングイディオムにつながるものを修正することに焦点を合わせたいと思います。 これを適切な方法でサポートするのは良いことですが、私が個人的に望んでいることは他にもたくさんあります。彼らは限られた時間を最初に費やします。 これはそのリストのずっと下にあります。

@MikeyBurkman優先順位の質問は有効です。 私の主な関心事は、この問題を閉じてそれを書き留めるという@RyanCavanaughの決定です。 このスレッドで指摘されたすべての問題を却下することは、（サブセットではなく）Javascriptの「スーパーセット」であるTypescriptの表明された使命と直接矛盾します。

ええ、私は間違いなくこの問題を解決すべきではないことに同意することができます。それは_おそらく_最終的に修正されるべきものだからです。 （私は本当にそうなるとは思えませんが。）

これを適切な方法でサポートするのは良いことですが、私が個人的に望んでいることは他にもたくさんあります。

TypeScriptの重要な側面を過小評価していると思います。それは、既存のDOMAPIと既存のJSAPIをより安全に使用できるようにするためです。 それは、あなた自身のコード以上のものを、そのバブルの中に安全に保つために存在します。

これが私の見解です。私はコンポーネントライブラリを構築しますが、必ずしも意図的にセッターとゲッターの間にこの不一致が存在するようにするわけではありません。 ライブラリが他のシステムとインプレースでインターフェースする必要がある方法に基づいて、私の手が強制されることがあります。 たとえば、Angularは、ターゲットタイプの知識に基づいて型強制を行うのではなく、マークアップからのコンポーネントのすべての入力プロパティを文字列として設定します（少なくとも最後にチェックしました）。 それで、あなたは文字列を受け入れることを拒否しますか？ タイプを使用するのがひどくなるとしても、すべてを文字列にしますか？ または、TypeScriptで行うことを実行し、次のようなタイプを使用しますか？ 色を付けますが、ゲッターの使用はひどいものにします。 これらはすべて、型システムからの追加の表現力が役立つとしたら、安全性を低下させるかなりひどいオプションです。

問題は、これらの問題を引き起こすのはAngularだけではないということです。 Angularは、プロパティセットで自動強制が発生するDOMの多くのシナリオを反映しているため、この状況で終了しましたが、ゲッターは常に予想される特異なタイプです。

少しアップスレッドを見てください： Angularはあなたが思っているよりもはるかに悪いです。

私にとっては、キーと値のペアを格納できる汎用ストレージのラッパーを作成し、ユーザーを特定のキーに制限したい場合に、通常は問題になります。

class Store {
  private dict: Map<string, any>;

  get name(): string | null {
    return this.dict.get('name') as string | null;
  }

  set name(value: string) {
    this.dict.set('name', value);
  }
}

このような制約が必要です。値が以前に設定されていない場合、ユーザーはnullを取得できますが、 nullに設定することはできません。 現在、セッターの入力タイプにはnullを含める必要があるため、これを行うことはできません。

@ fan-tom、この問題を再開する必要がある理由の優れたユースケース！ 来てください。

この号の賛成票数は非常に多いです。

これはTSチームのプロジェクトであるため、好きなように好きなように行うことができます。 しかし、これを外部のユーザーコミュニティにとって可能な限り役立つものにすることを目指しているのであれば、TSチームがコミュニティの多数の投票を十分に考慮できることを願っています。

typescriptlang.orgのホームページは、次のように記載されている場合、現在不正確です。

TypeScriptは、プレーンJavaScriptにコンパイルされるJavaScriptの型付きスーパーセットです。

TypeScriptは、JavaScriptの_subset_の型付き_superset_であり、プレーンJavaScriptにコンパイルされます。 ：スマイリー：

TypeScriptは、プレーンJavaScriptにコンパイルされるJavaScriptのサブセットの型付きスーパーセットです。

もっと外交的に言えば、チームが型システムモデリングからこの種の意見を省略した場合、それはJavaScriptの意見のあるスーパーセットであると言えると思います。

彼らは、「私たちが行うのは難しいので、これをモデル化することはしません。とにかく、あなたがそれを行うべきではないと思います」と言っています。 しかし、JavaScriptはあなたがすべきではないことでいっぱいであり、一般的な戦略はJavaScriptについて意見が分かれていないように思われるため、一般的にTypescriptは、意志とノウハウがあれば、これらのことを妨げることはありません。 Typescriptとして実行することはできますし、実行することもできません。

そのため、APIがセッターベースの強制を実行してはならないという信念を引用して、この一般的な（DOMで使用される！）シナリオのモデル化を拒否するのは非常に奇妙です。

現在、これは不可能のようであり、私は次のようなものに頼らなければなりません。

class MyClass {

    private _myDate: moment.Moment;

    get myDate(): moment.Moment {
        return this._myDate;
    }

    set myDate(value: moment.Moment) {
        assert.fail('Setter for myDate is not available. Please use: setMyDate() instead');
    }

    setMyDate(value: Date | moment.Moment) {
        this._myDate = moment(value);
    }
}

その値を設定するのがそれだけの場合は、コンストラクターを追加し、そこでカスタムセッター関数を呼び出すのが最善の方法です。

constructor(value: Date | moment.Moment) {
    this.setMyDate(value);
}

値を直接割り当てる場合の問題は依然として残っています。

5.5年以上経った後、これに関する更新はありますか？

ラベルが示すように@xhliuは、設計上の制限であり、対処するには複雑すぎるため、問題は解決されています。 私はアップデートを期待していません。 クローズされた問題の時間の長さは、ある意味無関係です。

再開してください。 また、これはインターフェイスレベルで追加する必要があります。 典型的な例は、読み取りと書き込みが可能なものに対して完全な柔軟性を備えたプロキシを実装する場合です。

@xhliu ...複雑すぎて対処できません...

https://ts-ast-viewer.com/#code/MYewdgzgLgBFCm0DyAjAVjAvDA3gKBkJgDMQQAuGAIhQEMAnKvAXzzwWXQDpSQg

const testObj = {
    foo: "bar"
}

testObj.foo

シンボルfooには次のように書かれています。

  foo
    flags: 4
    escapedName:"foo"
    declarations: [
      PropertyAssignment (foo)
    ]
    valueDeclaration: PropertyAssignment (foo)

ここには、TSに代わって優れた設計である、追加情報のための多くの余地があります。 これを設計した人は、おそらく将来的に追加機能（大きな機能でも）を可能にするために特別に設計しました。

この時点からの投機的：

（擬似コードの例で） accessDelclaration: AccessSpecification (foo)を宣言できる場合、シンボルfooとその宣言を認識しているPropertyAccessExpressionは、条件付きで「accessDelclaration」が存在するかどうかを確認できます。代わりに、そこからの入力を使用してください。

そのaccessDelclarationプロパティを「foo」シンボルに追加する構文が存在すると仮定すると、PropertyAccessExpressionは、 ts.createIdentifier("foo")から取得したシンボルから「AccessSpecification」をプルして、さまざまなタイプを生成できるはずです。

ts.createPropertyAccess(
  ts.createIdentifier("testObj"),
  ts.createIdentifier("foo")
)

投機的には、この課題の最も難しい部分は、構文（またはおそらく会社の哲学？）の周りの自転車の脱落の量である可能性が高いようですが、実装の観点からは、ツールはすべてそこにあるはずです。 単一の条件がts.createPropertyAccess()関数に追加され、その条件とその効果を表すDeclarationクラスをオブジェクトプロパティのシンボルに追加する必要があります。

これがどうしても必要な理由（特にDOMとAngularの場合）には、多くの良い例が書かれています。

stringをwindow.locationに割り当てることが機能せず、 as anyの回避策を実行しなければならなかった、古いJSコードをTSに移行したときに、今日これに見舞われたことを付け加えておきます。 😟

Window.location読み取り専用プロパティは、ドキュメントの現在の場所に関する情報を含むLocationオブジェクトを返します。

Window.locationは読み取り専用のLocationオブジェクトですが、DOMStringを割り当てることもできます。 これは、ほとんどの場合、文字列であるかのようにlocationを操作できることを意味します。location=' http://www.example.com'はlocation.href='http://www.example.com 'の同義語です。 。
ソース

stringをwindow.locationに割り当てることが機能せず、 as anyの回避策を実行する必要があったTSに古いJSコードを移行する

それは素晴らしい例です。

TSにはこれが必要です。 これはJavaScriptのごく普通の部分です。

現在の号はクローズされたようです。 しかし、私が理解しているように、この機能は実現されていませんか？

@AGluk 、この問題を再度開く必要があります。