12

＃12は＃6532でクローズされているため、この問題は範囲外のようです。
さまざまなアクセス修飾子を実装する計画はありますか？
readonlyは、プロパティがクラス内で実際に書き込み可能である可能性があるため、ここで説明されていることを解決するには十分ではないためです。

私はまた、私の例を関連する問題からここに移すべきだと信じています：

declare abstract class Emitter {
    new (): Emitter;
    on: (name:string, handler: (arg:any) => void) => void;
    off: (name:string, handler: (arg:any) => void) => void;
    protected emit: (name:string, arg:any) => void;
}

class Person extends Emitter {
    constructor(name:string) {
        super();
        this.name = name;
    }

    private _name:string;
    get name() {
        return this._name;
    }
    set name(value) {
        if (this._name !== value) {
            this._name = value;
            this.emit('change:name', value);
            //this way is better
            this.updatedAt = new Date();
            //than this way
            this.setUpdatedAt(new Date());
        }
    }

    ////
    private _updatedAt:Date;
    get updatedAt() {
        return this._updatedAt;
    }
    private set updatedAt(value) { //Getter and setter do not agree in visibility
                //some logic and a simple readonly (our absence of a setter) is not enough
        if (this._updatedAt !== value) {
            this._updatedAt = value;
            this.emit('change:updatedAt', value);
        }
    }

    //// method implementation - but what's the point in it?
    private setUpdatedAt(value) {
        if (this._updatedAt !== value) {
            this._updatedAt = value;
            this.emit('change:updatedAt', value);
        }
    }
}

const entity = new Person('Mike');
entity.on('change:updatedAt', console.log.bind(console));
entity.name = 'Thomas';
//but manually setting updatedAt should be forbidden
entity.updatedAt = new Date(); //restricted

ここで、プロパティupdatedAtは実際にはセッターを持つことができますが、 Personの外部からアクセスできないようにする必要があります。 さらに、このセッターには複雑なロジックが含まれており、単純な読み取り専用またはセッターがないだけでは不十分です。

プライベートセッターは、追加のロジック（放出など）を持つプライベートメソッドの単なる構文糖衣であることに同意しますが、フィールドに関連するロジックの一部がプロパティ（ゲッター）にあり、別のロジックの一部がメソッド（プライベートセッター）にある場合は一貫性がないと思います。

このように、ゲッター/セッターはC#で実装されます。このコントラクトは実行時に失われますが、コンパイル時に異なる可視性を許可すると便利だと思います。

ここでの推奨事項は、パブリック読み取り専用ゲッターとプライベート/保護されたバッキングフィールドを使用することです。

アクセサーは、型システムのプロパティと対称的です。 私たちが行うことはすべて、タイプで明示され、プロパティで表現可能である必要があります。 private_set / public_getを有効にするために新しいアクセス修飾子を追加すると、言語と学習曲線の複雑さが増し、これから得られる値は、追加された複雑さと一致しません。

とにかく、将来再び検討される場合に備えて、これに+1を追加します...

まだ見たいです。 C＃にはそれがあり、多くの状況で非常に便利です。特に、クラスの外部で読み取りたいが、private / protectedで内部的にのみ設定するフラグがある場合に役立ちます。

あまり使われていないというのは、パターンが使えないので使わないという茶番だと思います。

これは言語への良い追加です：これが（タイプスクリプトプログラマーの観点から）追加する複雑さの量は小さいです。 概念は理解しやすく、コンパイラーは、スコープが原因でゲッターまたはセッターにアクセスできない理由を示唆する適切なエラーメッセージを提供できる必要があります。

私は上記のユーザーに同意します。これは他のほとんどの言語の標準です。 それに対する議論は重要ではなく、実装を再検討する必要があります。

私は実際にあなたがTSでこれを行うことができないことに驚いていました...問題への+1。
これで学習曲線が増えることはないはずです

private get x() { ... }
public set x(value) { ... }

Imo英語が読めるなら、ここでprivate（protected）/ publicが何を意味するのかは自明です。 また、そもそもアクセサーを定義している場合、おそらくそれらが何のためにあるのかをすでに知っているでしょう。

追伸：エラーについて：「ゲッターとセッターのアクセサーは可視性に同意しません」-まあ：それはまさに私が彼らにしてもらいたいことです

これが便利な2つのユースケースを次に示します。

Backbone.js、醜い.get()と.set()の呼び出しを避けるために：

class Whatever {
    public get rotation(): number {
        return this.get('rotation');
    }
    private set rotation(rotation: number) {
        this.set('rotation', rotation);
    }
}

サブクラスが変更できるプロパティ：

class ExtendMe {
    public get someProperty(): string {
        // some stuff
    }
    protected set someProperty(prop: string) {
        // some stuff
    }
}

TypeScriptを使い始めて以来、私を悩ませてきたので、これを絶対に見たいと思います。

私はこの機能を要求する人々に同意します。 public get（）メソッドを試してみましたが、セットとgetが可視性について合意している必要があることに驚きました。

複雑すぎると主張して皆さんを読んでいます。 「C ++の方法」を思い出して、それが次のものと異なる理由：

private _myAttribute: string;
get myAttribute(): string {...}
setMyAttribute(value: string) {...}

私はこれの多くのユースケースを見ることができます、それが私が今ここにいる理由です。
myAttributeをパブリックにアクセス可能にしたいが、そのクラス内でのみ変更できるようにするにはどうすればよいですか？
属性が変更されるたびにカスタムロジックを追加したい場合はどうなりますか？
これはビジネスルールである場合もあれば、デバッグ目的などのブレークポイント条件とともに、特定の値が割り当てられている理由を理解するための単なるログである場合もあります。

基本的に、メソッドを呼び出すのではなく、値を割り当てているように見える構文シュガーと一緒に属性を変更するたびに、メソッドを使用する必要があります。
C＃にはこのためのプロパティの概念があり、TSはその概念を継承していると思いましたが、異なるアクセシビリティを許可しないことは、私のように考えて「C ++スタイル」にフォールバックさせる人々にとって大きな制限です。

「難しすぎる」ということは、信じられないほど便利な機能を実装しない理由にはなりません。

私の+1を追加します。 非常に多くの点で完全にこれを行うことができない言語では、私には非常に奇妙に思えます。

この問題がクローズとしてマークされていることに驚いた。 この機能はコミュニティによって望まれています。 再開してください。
+1

12はこの問題に対処していないため、この問題を参照するコメントでこの問題を閉じるべきではありません。

私見これは素晴らしい機能ですが、私が理解している限りでは、「私は毎回_propertyを書きたくないのではなく、プライベートセットプロパティを使用したい」という状況にすぎません。

TypeScriptコアコード自体に非常に複雑なものを追加する（覚えておいてください-不必要な複雑さ-開発の速度が遅くなり、デバッグ、テストの記述にかかる時間が長くなります-最終的にはリリースの頻度が少なくなります）が、1つのシンボルの書き込みまたは書き込みを減らすという選択肢がある場合その1つのシンボルとそれをうまく処理します...私はむしろ毎回もう一度1つのシンボルを書きたいです。 結局、私はTSコアの貢献者ではなく、この砂糖の複雑さの可能性に対処したくありません。

それは大したことではありません。 また、リクエストを実装するには複雑すぎると判断するには勇気と知恵が必要です（結果としてコード全体の複雑さが増します）。そのため、TypeScriptを開発している皆さんに敬意を表し、作業に感謝します。

（psは、なぜそうしないのかを学ぶためにここに来ました-結局、私の考えを変えて、これに対処します。_property=..。
そしてまだ幸せになります）

@idchlife setプロパティの目標は、値を割り当てるときに開発者に1つのアンダースコアを保存することではありません。 setプロセスにロジックを追加することもできます。

この号を再度開いてください。 これは明らかに非常に望ましい機能です。

+1これが再考されるのを見たいです。

非常に奇妙なことに、他の多くの言語がすでにこれを行っている場合、あなたの論理的根拠は「これは物事を混乱させるでしょう」です。

すべての👍はあまり機能していないので、もう1つ👍コメントを付けてスパムを送信します。

これは、物事をより読みやすく、迅速に実装するのに役立つ構文糖衣です。 多くの言語には、Typescriptを含む構文糖衣構文があります。 それをしないという本当の正当な理由はないようであり、複雑すぎることは決して何かをしない正当な理由ではありません。それは怠惰な警官のようなものです。 複雑すぎる問題を解決することは、ほとんどの人がソフトウェアエンジニアリングに惹かれる理由の1つです。 したがって、この複雑な問題を取り上げて、それほど複雑ではない方法で解決してください。 リファクタリングとリスクの高い変更が必要ですか？ たぶん、しかしそれは物事が成し遂げられる方法です。

それでも望ましい。 他の言語は、get-およびset-機能の異なる可視性をサポートするのに問題はありません。 侮辱に負傷を加えるために、TypescriptはC＃と同じようにMicrosoftによって作成されていますが、C＃はそれを完全にサポートしています。

public string myPropertyWithLimitedAccess { get; private set; }   

あれ見てよ。 美しく読みやすく、複雑なことはまったくありません。

https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/auto-implemented-properties

サポートしない理由はほとんどありません。

private _myProperty: string;

public get myProperty(): string { return this._myProperty; }
private set myProperty(value: string) { this._myProperty = value; }

Typescriptは、主に.NET開発者がブラウザのフロントエンドでの作業に慣れるために作成されたため、奇妙な設計上の決定にボーナスポイントがあります。

+1
Typescriptは間違いなくこの機能の恩恵を受けるでしょう！

TypeScriptはC＃の後でも素晴らしいですが、この無意味な制限は私をかなり頻繁に苛立たせます。 再度開いてください。

言語の複雑さが増すだろう

readonly [P in keyof T]: T[P]のようなものと比較して、これは本当にこの複雑なものですか？

バンプ。 誰もがこの機能を望んでいます。 TypesScriptコミュニティが決定するべきではありませんか？

言語の複雑さが増すだろう

readonly [P in keyof T]: T[P]ようなものと比較して、これは本当にこの複雑なものですか？

複雑さは、他の言語機能の相互作用に関係しています。 残念ながら私はそれを見つけることができませんが、IIRC RyanCavanaughは、この機能を使用して、クラス式を使用した継承を介して不変条件を設定し、違反することができる例を示しました。 特定の宣言を書くのが簡単だからといって、それが物事にどのように影響するかを常に簡単に推論できるわけではありません。

問題は、特定の機能がどの問題を解決し、どの問題を作成するかです。 前者は答えるのが簡単です、後者は驚くほど答えるのが難しいかもしれません。 残念ながら、TSチームは、問題を説明するのではなく、「OMGの複雑さ」で応答するように見えることがあります。 （公平を期すために、n回目のクエリxへの回答に費やす時間が長いほど、開発に必要な時間は少なくなります。）

実際に言語を開発している専門家の間でコンセンサスがあれば、それはあなたに何かを教えてくれるはずなので、私は「コミュニティが決定するべきではない」という概念に100％同意しません。 しかし、私はこのように要求されたもので、トレードオフが何であるか、そしてなぜ彼らがそれに反対しているのかについてのチームからの思慮深い説明を求めるのはそれほど多くないと思います。

そして個人的には、この場合のトレードオフは1000％の価値があると思います。 しかし、わざわざそれを特定して機能させることができなければ、文句を言う権利はあまりないのではないかと思います。

この問題を再検討する良い機会でしょうか？

readonly修飾子は素晴らしいですが、クラスの内部で値を変更し、外部ですべてを読み取り専用にしたい場合が多くあります。

プライベートバッキングフィールドとプロパティが追加するノイズが気に入らないため、プロパティをreadonlyにしないことを選択することがよくあります。

これを行うための構文糖衣があれば素晴らしいと思います。 何かのようなもの：

// Option 1: C# style
public name: string { get; private set; }

// Option 2: Swift style
private(set) name: string

// Option 3: Swift struct-style
public readonly name: string

mutating changeName(name: string) {
  this.name = name
}

// Option 4: New keyword
public frozen name1: string
public readonly name2: string

私はオプション2が好きです。それはTypeScript言語にうまく適合します。

オプション3では、 mutatingとしてマークされている関数の読み取り専用フィールドのみを変更できます。

オプション4では、 frozenはコンストラクターでのみ設定でき、 readonlyはこのクラスの内部で設定でき、外部クラスやこのクラスから継承するクラスでは設定できません。

参考までに、より柔軟な修飾子に関する@yvbeekのアイデアは、 https：//github.com/microsoft/TypeScript/issues/37487での議論に適しています。

この問題は特にゲッターとセッター向けであり、非常に多くの賛成票があります。 ゲッターとセッターに異なるアクセス修飾子を与えると便利だと思います（TypeScriptチームが前進するのに許容できるものであると判断した場合は、既存の修飾子のセットを＃37487で更新できます）

実際に言語を開発している専門家の間でコンセンサスがあれば、それはあなたに何かを教えてくれるはずなので、私は「コミュニティが決定するべきではない」という概念に100％同意しません。 しかし、私はこのように要求されたもので、トレードオフが何であるか、そしてなぜ彼らがそれに反対しているのかについてのチームからの思慮深い説明を求めるのはそれほど多くないと思います。

@snarfblam無関係なコメントでこのスレッドを詰まらせないでください、しかしあなたは政府が運営されるべき方法の核となる原則を明らかにしたと思います。

この機能がないことは私にとって本当に苦痛であり、（とりわけ）TS / NodeJSからもっと...タイプセーフに切り替えるようになりました。 それはすべて問題なくダンディですが、多くのデータ構造（何度も深くネストされている）を含む複雑なプロジェクトで作業していて、データを適切にモデル化できない場合、これは「大規模な言語」ではないと感じます。男の子」。

私の特定のケースでは、プロパティを読み取り専用にしたいのですが、内部から変更可能であり、JSONにシリアル化することもできます。 ジャンプするにはフープが多すぎます。

この機能は、_optionalchaining_と同じパスをたどる場合があります。 人々は何年もの間この機能を要求し、それが実用的であり、他の言語も同じ機能を提供するため、最終的には言語に追加されます。

それ以外の場合は、一部の実装がEcmaScriptの一部になり、TypeScriptに移行することを期待しています。

私は最近typescriptに切り替えたばかりで、その言語が大好きです。 他の言語に存在するこの実用的な機能がここに実装されていないことに本当にうんざりしています。 言語にどれほど複雑になると思われるかに関係なく、将来のリリースで追加することを再検討してください。

私はそのようにゲッターでc＃に似た何かを達成しました：

export class I18nService {
  private static ref: I18nService;

  public static get instance(): I18nService {
    if (!I18nService.ref) {
      I18nService.ref = new I18nService();
    }

    return I18nService.ref;
  }
}

次のようなタイプエラーは理解しやすく、複雑ではありません。

Property 'foo' is writable only in protected scope within class 'Blah' and its subclasses.

また

Property 'foo' is readable only in protected scope within class 'Blah' and its subclasses.

など、およびprivateと同様です。

それは正直言って複雑ではありません。

ところで、私もこの問題に遭遇しました。その間、この種の「ハック」を使用しています。

// somewhere.ts
declare global {
    type Writable<T> = { -readonly [P in keyof T]: T[P]; }
}

// example.ts
class Example {

    public readonly prop: number;

    public doSomething(n: number): void {
        (this as Writable<this>).prop = n;
    }
}

技術的には、これはどこでも使用できますが、この回避策の使用は、クラスメソッド内のコードに制限する必要があります。

ところで、私もこの問題に遭遇しました。その間、この種の「ハック」を使用しています。

私はこのアイデアを自分で試しましたが、問題は、「パブリック読み取り専用」プロパティと真の読み取り専用プロパティを区別する方法がないことです。 このため、汎用ソリューションとしてはあまり適していません。