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 속성은 실제로 setter 를 가질 수 있지만 Person 외부에서 액세스할 수 없어야 합니다 . 게다가 이 setter는 복잡한 로직을 포함하고 있으며 단순한 readonly 또는 setter의 부재로는 충분하지 않습니다.

private setter는 추가 논리(예: 방출)가 있는 private 메서드에 대한 구문 설탕이라는 데 동의하지만 필드와 관련된 논리의 일부가 속성(getter)에 있고 다른 논리가 메서드(private setter)에 있는 경우에는 일관성이 없다고 생각합니다. .

이 방법으로 getters/setters는 C# 에서 구현됩니다. 이 계약은 런타임에 손실되지만 컴파일 시간에 다른 가시성을 허용하는 것이 유용할 것이라고 생각합니다.

여기에서 권장하는 것은 공개 읽기 전용 getter와 개인/보호된 지원 필드를 사용하는 것입니다.

접근자는 유형 시스템의 속성과 대칭입니다. 우리가 하는 모든 일은 유형에 명시되어야 하고 속성에 표현 가능해야 합니다. private_set/public_get을 활성화하기 위해 새로운 접근 수정자를 추가하면 언어의 복잡성과 학습 곡선이 증가하고 여기서 얻은 값은 추가된 복잡성과 일치하지 않습니다.

어쨌든 이것을 위해 내 +1을 추가하십시오. 나중에 다시 고려되는 경우를 대비하여 ...

나는 아직도 이것을 보고 싶다. C#에는 이 기능이 있으며 특히 클래스 외부에서 읽고 싶지만 내부적으로만 private/protected로 설정되는 플래그가 있는 경우 많은 상황에서 매우 유용합니다.

자주 사용하지 않는다는 제안은 패턴을 사용할 수 없기 때문에 사용하지 않는다는 점에서 희극이라고 생각합니다.

이것은 언어에 좋은 추가 사항입니다. (타입스크립트 프로그래머의 관점에서) 추가되는 복잡성의 양은 적습니다. 개념은 이해하기 쉽고 컴파일러는 범위 지정으로 인해 getter 또는 setter에 액세스할 수 없는 이유를 암시하는 좋은 오류 메시지를 제공할 수 있어야 합니다.

나는 위의 사용자에 동의합니다. 이것은 대부분의 다른 언어의 표준입니다. 이에 대한 주장은 중요하지 않으며 구현을 재고해야 합니다.

나는 실제로 당신이 TS에서 이것을 할 수 없다는 것에 놀랐습니다 ... 문제에 +1.
이것으로 학습 곡선이 증가해서는 안됩니다.

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

영어를 읽을 수 있다면 여기에서 private(protected)/public이 무엇을 의미하는지 자명합니다. 또한 처음에 접근자를 정의하는 경우 - 이미 접근자가 무엇인지 알고 있을 것입니다.

추신 오류 정보: "Getter 및 setter 접근자가 가시성에 동의하지 않습니다." - 글쎄: 이것이 바로 내가 원하는 작업입니다.

다음은 이것이 편리한 두 가지 사용 사례입니다.

.get() 및 .set() 호출을 피하기 위해 Backbone.js:

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를 사용하기 시작한 이후로 저를 괴롭히고 있기 때문에 이것을 보고 싶습니다.

이 기능을 요청하는 사람들의 의견에 동의합니다. 방금 공개 get() 메서드를 사용하려고 했고 내 집합과 get이 가시성에 대해 동의해야 한다는 사실에 놀랐습니다.

나는 그것이 너무 복잡하다고 주장하는 당신들을 읽었습니다. "C++ 방식"이 다음과 다른 이유를 기억하십시오.

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

나는 이것에 대한 많은 사용 사례를 볼 수 있습니다. 그래서 제가 지금 여기 있습니다.
myAttribute를 공개적으로 액세스할 수 있지만 해당 클래스 내에서만 수정할 수 있도록 하려면 어떻게 해야 합니까?
속성이 수정될 때마다 일부 사용자 정의 논리를 추가하려면 어떻게 합니까?
비즈니스 규칙이 될 수도 있고 디버깅 목적을 위한 중단점 조건과 함께 특정 값이 할당된 이유를 이해하기 위한 로깅일 수도 있습니다.

기본적으로 우리는 메서드를 호출하는 대신 값을 할당하는 것처럼 보이게 하는 구문 설탕과 함께 속성을 수정할 때마다 메서드가 사용되기를 원합니다.
C#은 이에 대한 속성의 개념을 가지고 있고 TS가 그 개념을 계승했다고 생각했지만, 다른 접근성을 허용하지 않는 것은 나와 같은 생각을 하고 우리를 "C++ 스타일"로 되돌아가게 만드는 사람들에게 큰 한계입니다.

"너무 어려워"라고 해서 엄청나게 유용한 기능을 구현하지 않을 이유가 되어서는 안 됩니다.

내 +1을 추가합니다. 많은 면에서 너무도 완전한 언어로 당신이 이것을 할 수 없다는 것이 제게는 매우 이상하게 보입니다.

이 문제가 종료된 것으로 표시되어 놀랐습니다. 이 기능은 커뮤니티에서 원하는 기능입니다. 다시 열어주세요.
+1

12에서는 이 문제를 다루지 않으므로 이 문제를 언급하는 주석으로 이 문제를 종료해서는 안 됩니다.

IMHO 이것은 좋은 기능이지만 내가 이해하는 한 공정합니다. "글쎄, 나는 매번 _property를 쓰고 싶지 않습니다. 대신에 private set 속성을 사용하고 싶습니다"라는 상황입니다.

TypeScript 핵심 코드 자체에 엄청난 복잡성을 추가하는 선택이 있는 경우(기억하십시오, 더 불필요한 복잡성 - 개발 속도 감소, 디버그에 더 많은 시간, 결국 테스트 작성 - 덜 빈번한 릴리스) 기호 1개 쓰기 또는 쓰기 그 1 심볼을 잘 처리하고 ... 차라리 1 심볼을 매번 한 번 더 쓰겠습니다. 결국 저는 TS 코어에 기여한 사람이 아니며 이 설탕의 가능한 복잡성을 처리하고 싶지 않습니다.

딜브레이커가 아닙니다. 또한 구현하기에 너무 복잡한 요청을 발견하는 데는 용기와 지혜가 필요합니다(결과적으로 전체 코드 복잡성이 증가함). 따라서 TypeScript를 개발하는 여러분께 경의를 표하고 작업에 감사드립니다!

(ps는 왜 안되는지 배우기 위해 여기에 왔습니다 - 결국 내 마음이 바뀌었고 이것을 다룰 것입니다._property = ...
그리고 여전히 행복할 것입니다)

@idchlife set 속성 목표는 값을 할당할 때 개발자에게 밑줄 하나를 저장하는 것이 아닙니다. set 프로세스에 일부 논리를 추가할 수도 있습니다.

이 문제를 다시 여십시오. 이것은 분명히 매우 원하는 기능입니다.

+1 나는 이것을 재검토하는 것을 보고 싶다.

다른 많은 언어가 이미 이 작업을 수행할 때 "이것은 혼란을 일으킬 것"이라는 논리가 매우 이상합니다.

모든 👍가 별 일을 하고 있지 않기 때문에 👍 댓글 하나만 더 달겠습니다.

이것은 더 읽기 쉽고 빠르게 구현하는 데 도움이되는 구문 설탕이 될 것입니다. Typescript를 포함하여 많은 언어에 구문 설탕이 있습니다. 하지 말아야 할 좋은 이유가 없는 것 같고 너무 복잡하다고 해서 하지 말아야 할 좋은 이유가 될 수 없습니다. 너무 복잡한 문제를 해결하는 것은 대부분의 사람들이 소프트웨어 엔지니어링에 끌리는 이유 중 하나입니다. 따라서 이 복잡한 문제를 그렇게 복잡하지 않은 방식으로 해결하십시오. 리팩토링과 위험한 변경이 필요합니까? 어쩌면 그렇게 할 수 있습니다.

여전히 바람직합니다. 다른 언어는 get 및 set 기능에 대해 다른 가시성을 지원하는 데 문제가 없습니다. 모욕에 상처를 주기 위해 Typescript는 C#과 마찬가지로 Microsoft에서 만들지만 후자는 완전히 지원합니다.

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] 와 비교할 때 이것이 정말 복잡합니까?

충돌. 모두가 이 기능을 원합니다. TypeScript 커뮤니티가 결정해야 하지 않습니까?

언어의 복잡성을 증가시킬 것입니다

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에 대한 논의에 더 적합합니다.

이 문제는 특히 getter 및 setter를 위한 것이며 매우 높은 수의 찬성표를 받았습니다! getter와 setter에 서로 다른 액세스 수정자를 제공하는 것이 유용할 것이라고 생각합니다(TypeScript 팀이 앞으로 나아갈 수 있는 것으로 결정한 경우 #37487에서 기존 수정자 세트를 업데이트할 수 있습니다)

나는 "커뮤니티가 결정해야 하는 것"이라는 개념에 100% 동의하지 않습니다. 왜냐하면 실제로 언어를 개발하는 전문가들 사이에 합의가 있다면 그것이 당신에게 무언가를 말해줄 것이기 때문입니다. 그러나 이와 같이 요청한 사항에 대해 팀에서 절충안이 무엇인지, 왜 반대하는지에 대한 사려 깊은 설명은 너무 많은 것을 요구하지 않는다고 생각합니다.

@snarfblam 이 스레드를 관련 없는 댓글로

이 기능이 없다는 것은 저에게 정말 고통스러운 일이며 (무엇보다도) 제가 TS/NodeJS에서 더... 유형이 안전한 것으로 전환하게 만들었습니다. 모두 훌륭하고 멋집니다. 하지만 많은 데이터 구조(깊게 여러 번 중첩됨)가 있는 복잡한 프로젝트에서 작업할 때 데이터를 제대로 모델링할 수 없으면 이것이 "큰 언어"가 아니라는 느낌을 받습니다. 소년들".

내 특별한 경우에는 속성을 읽기 전용으로 원하지만 내부에서 수정할 수 있고... 또한 JSON으로 직렬화됩니다. 넘어야 할 골이 너무 많습니다.

이 기능은 _선택적 연결_과 동일한 경로를 따를 수 있습니다. 사람들은 몇 년 동안 이 기능을 요구하고 마침내 언어에 추가될 것입니다. 실용적이고 다른 언어에서도 동일한 기능을 제공하기 때문입니다.

그렇지 않으면 일부 구현이 EcmaScript의 일부가 된 다음 TypeScript에 적용되기를 바랍니다.

나는 최근에 typescript로 전환했고 언어를 사랑해 왔습니다. 다른 언어에 존재하는 이 실용적인 기능이 여기에서 구현되지 않았다는 사실이 정말 안타까웠습니다. 언어에 추가되는 복잡성에 관계없이 향후 릴리스에 추가하는 것을 재고하십시오.

그런 식으로 getter를 사용하여 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 와 유사합니다.

솔직히 복잡하지 않습니다.

BTW, 나도이 문제를 우연히 발견했으며 그 동안 이런 종류의 "해킹"을 사용하고 있습니다.

// 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;
    }
}

기술적으로 이것은 모든 곳에서 사용할 수 있지만 이 해결 방법을 사용하는 것은 클래스 메서드 내부의 코드로 제한되어야 합니다.

BTW, 나도이 문제를 우연히 발견했으며 그 동안 이런 종류의 "해킹"을 사용하고 있습니다.

나는 이 아이디어를 가지고 놀았지만 문제는 "공개 읽기 전용" 속성과 진정한 읽기 전용 속성을 구별할 방법이 없다는 것입니다. 따라서 범용 솔루션으로는 적합하지 않습니다.