TypeScript 팀은 구문과 기호/문자 접두사의 사용에 대해 어떻게 생각합니까?

나는 개인적으로 그것이 끔찍해 보인다고 생각하지만 분명히 기술적 한계가 있습니다(내가 완전히 이해하지 못하는 이유로 가시성을 식별해야 하는 사용법).

TypeScript가 현재의 private/protected 구문을 잃는 것을 보는 것은 슬플 것입니다. 이는 다른 여러 언어와 훨씬 더 깨끗하고 일관성이 있습니다. 이것이 일어날 가능성이 있습니까? 대안이 있습니까?

여기에 추가하기 위해 # 및 @ 기호를 전환할 가능성에 대한 이야기가 있습니다(즉, 데코레이터에 # 사용). 이는 분명히 TypeScript에도 영향을 미칩니다. .

저도 '끔찍하다'고 생각합니다. 제 생각에는 :: 바인드 연산자처럼 실제로는 그렇게 멀리 만들지 않았습니다. T39를 사용하여 경로를 조금 더 아래로 내려갈 때까지 구현하려고 시도하는 것조차 보류할 가치가 있습니다. 나는 그것이 약간의 거친 주행이 될 것이라고 매우 의심합니다. 또한 모든 액세스 사이트를 다시 작성해야 하기 때문에 이를 지원하는 다운 에미트는 다소 어려울 것으로 생각됩니다.

내가 완전히 이해하지 못하는 이유로 사용법은 가시성을 식별해야합니다.

주로 사용 사이트에서 속성을 조회하는 방법을 식별해야 하기 때문에 하위 클래스가 상위 개인 속성에 대해 "알" 필요 없이 동일한 개인 이름을 재사용할 수 있도록 다른 조회 알고리즘이 필요하기 때문입니다.

제안된 구문의 한 가지 장점은 this 생략하고 #field 직접 사용할 수 있다는 것입니다. 또한 인장은 데코레이터(https://github.com/tc39/proposal-private-fields/issues/32)로 교체될 수 있으며 대신 @ 가 사용되므로 @field , 루비처럼. 이 구문이 여전히 못생겼습니까?

나는 사람들이 "비공개" 키워드 기반 솔루션에 만족하지 않을 것이라고 생각합니다.

JavaScript가 하는 것처럼 일반적인 eval 를 지원하는 동안 그렇게 하는 좋은 방법이 보이지 않습니다. 구체적인 토큰은 약간의 차별화를 허용하고 TypeScript에서와 같이 정적 유형 시스템을 기반으로 하지 않는 개인 상태를 지원하는 것을 가능하게 합니다. . 우리는 https://github.com/tc39/proposal-private-fields/issues/14 에서 여러 구문 대안에 대해 논의했으며 TypeScript의 현재 구문은 항상 제대로 작동할 수 있는 것으로 보지 않습니다. 완전히 일반적인 JS 환경.

주로 사용 사이트에서 속성을 조회하는 방법을 식별해야 하기 때문에 하위 클래스가 상위 개인 속성에 대해 "알" 필요 없이 동일한 개인 이름을 재사용할 수 있도록 다른 조회 알고리즘이 필요하기 때문입니다.

JavaScript가 내부적으로 어떻게 작동하는지 더 알고 싶습니다. 나는 그것이 here and here 설명 된 방식으로 작동 할 것이라고 생각했지만 분명히 그렇지 않습니다. 성능에 상당한 영향을 미친다는 사실이 여전히 믿기지 않지만 비교할 수 있는 수치는 없습니다.

이 구문이 여전히 못생겼습니까?

기본적으로 그렇습니다. 더군다나 나머지 JavaScript 구문과 일치하지 않을 뿐만 아니라 다른 많은 언어와도 일치하지 않는 것으로 나타났습니다.

| 언어 | 구문 | 메모 |
| --- | --- | --- |
| C# | 개인 정수 x; | |
| C++ | 사적인:
정수 x; | |
| 자바 | 개인 정수 x; | |
| PHP | 개인 $x; | |
| 파이썬 | __x | "노코멘트" |
| 루비 | 사적인
def 메서드
# ...
끝 | 방법이지만 필드는 비공개입니다.
기본적으로 생각합니다. |
| 타입스크립트 | 개인 x; | |
| 비주얼 베이직 | 개인 x 정수 | |

위의 언어 중 _하나_를 제외한 모든 언어는 private 키워드를 사용하며 Python에는 어쨌든 "적절한" 개인 상태가 없는 것 같습니다.

Python을 제외하고(다시), 어떤 언어도 가시성에 따라 필드 선언 또는 필드 액세스를 다르게 형식화하지 않으며 필요한 경우 모두 새로운 가시성 수정자를 허용합니다.

나는 또한 # 및 @ 둘 다 데코레이터와 같은 것, 즉 케빈의 말에 따르면 "구문적으로 명령형 흐름의 '외부'"에 더 잘 작동한다고 생각합니다.

JavaScript가 하는 것처럼 일반 평가를 지원하는 동안 그렇게 하는 좋은 방법이 없습니다.

이 문제를 평신도 용어로 설명할 수 있습니까? (https://github.com/tc39/proposal-private-fields/issues/14에 있을 수 있음)

이러한 문제의 목록을 예제와 함께 한 곳에서 참조할 수 있도록 하는 것이 좋습니다.

성능에 상당한 영향을 미친다는 사실이 여전히 믿기지 않지만 비교할 수 있는 수치는 없습니다.

TypeScript에서와 같은 규칙에 비해 정말 비공개로 하고 싶다면 그렇게 할 것입니다. JavaScript에서 속성을 조회할 때마다 프로세스는 기본적으로 다음과 같습니다.

1. 자신의 재산에 대한 사례를 보십시오.
2. 소유 재산이 없는 경우 소유 재산에 대한 프로토타입을 살펴보십시오.
3. 속성을 찾을 수 없을 때까지 프로토타입 체인을 상승시킵니다.
4. 발견된 경우 속성 설명자(쓰기 가능, 가져오기, 설정, 구성 가능)를 처리합니다.
5. 찾지 못하고 읽히면 undefined 반환하거나 봉인 또는 동결되지 않은 경우 값을 자신의 속성으로 설정하고 쓰십시오.

이제 이름에 패턴이 없는 privates를 사용하면 고유한 속성이 없고 프로토타입 체인을 올라가지 않는 자체 private 속성과 같은 것을 갖게 됩니다. 그런 다음 개인 속성에 액세스할 수 있는 모든 작업에 대해서도 해당 속성을 찾아야 합니다. 어느 것이 참조되는지 확신할 수 없기 때문입니다. 정상적인 방법으로 검색한 다음 비공개에서 찾을 수 없는 경우에만 매우 위험할 수 있습니다. 프로토타입 체인에서 무언가를 찾았지만 비공개 버전도 있는 경우에는 어떻게 될까요?

가장 큰 문제는 JavaScript 클래스가 여전히 약간 잘못된 이름이라는 것입니다. 그것들은 본질적으로 프로토타입 상속 생성자 함수에 대한 구문 설탕입니다. tc39/proposal-private-fields#14에 추가하려고 하는 한 가지 생각이 있습니다.

이 문제를 평신도 용어로 설명할 수 있습니까?

호출 사이트를 다시 작성해야 하는 경우 다음과 같은 것을 지원할 수 없습니다.

class Foo {
    private foobar: string;
    baz() {
        const p = 'foo' + 'bar';
        console.log(this[p]);
    }
}

또는 eval 구조와 같은 용도. 비공개에 대한 인덱스 액세스 또는 평가 지원 없음과 같은 것을 지원하지 않도록 선택할 수 있지만 "왜 귀찮아"합니다. 이 모든 것이 제안서에서 어떤 식으로든 지적되었지만 사람들은 여전히 ​​"하지만 나는 사적인 것을 좋아합니다" 😁.

당신은 자신의 재산이 없을 것입니다, 당신은 자신의 사유 재산과 같은 것을 가질 것입니다

설명자에 visibility 항목이 있는 단일 속성 집합이 있는 경우 문제는 해당 속성이 현재 개체에 존재하지 않으면 상승할지 여부를 알 수 없다는 것입니다. 프로토타입 체인.

호출 사이트를 다시 작성해야 하는 경우 다음과 같은 것을 지원할 수 없습니다.

AFAIK, 어쨌든 지원되지 않습니다( ref ).

나는 여전히 평가 사례를 따르지 않습니다. 속성 이름이 계산된 후 속성 검사가 런타임에 발생할 것이라고 생각했습니다.

그러나 사람들은 여전히 ​​"하지만 나는 사적인 것을 좋아한다"

저는 그런 사람들 중 한 명도 되지 않고 문제를 이해하려고 노력하고 있지만 제안된 구문이 저를 불편하게 만듭니다. =)

알겠습니다. 이제 평가/재작성 사례를 이해한 것 같습니다. 클래스 내의 사용 사이트는 선언된 속성을 기반으로 가시성을 나타내도록 다시 작성되며 단순 조회가 아니면 불가능합니다.

설명자에 가시성 항목이 있는 단일 속성 집합이 있는 경우 문제는 현재 개체에 속성이 존재하지 않으면 프로토타입 체인을 상승할지 여부를 알 수 없다는 것입니다.

흠. 그러나 현재 클래스에 존재하지 않는다면 정의상 non-private가 아닌가요? 그렇다면 (일반 공개 속성 조회와 마찬가지로) 어쨌든 프로토타입 체인을 위로 이동해야 합니다. private 액세스에 대한 추가 작업은 없습니다.

(나는 아마도 명백한 것을 놓치고있을 것입니다)

그러나 현재 클래스에 존재하지 않는다면 정의상 non-private가 아닌가요? 그렇다면 (일반 공개 속성 조회와 마찬가지로) 어쨌든 프로토타입 체인을 위로 이동해야 합니다.

아니요, 당신은 올라가고 싶지 않습니다. 개인 레이블은 상속되지 않으며 하위 클래스는 마스킹/이름 충돌에 대해 걱정하지 않고 개인 레이블을 재사용할 수 있습니다.

@glen-84 언급한 두 게시물 모두 서명되지 않은 개인 상태에 문제가 있음을 나타냅니다. 그러한 문제에 대한 해결책에 대한 아이디어가 있습니까? 조회 체인을 복잡하게 만드는 것은 호환성 면에서 위험하고 자바스크립트를 좋은 성능으로 구현하기 어렵게 만들고(기존 프로그램을 느리게 만들 수 있음) 기본적으로 프록시와 제곱하는 것이 불가능하며 일반적으로 언어의 정신 모델을 상당히 복잡하게 만듭니다. 이미 비교적 복잡한 객체 시스템을 가지고 있음).

언어 간 비교에서 Ruby를 언급했습니다. 나는 Ruby가 @ _with_ 개인 상태의 좋은 예라고 생각합니다. sigil 없이 getter 및 setter 메서드를 호출할 수 있습니다.

아니요, 당신은 올라가고 싶지 않습니다. 개인 레이블은 상속되지 않으며 하위 클래스는 마스킹/이름 충돌에 대해 걱정하지 않고 개인 레이블을 재사용할 수 있습니다.

속성이 현재 클래스에 없으면 위로 이동하여 공개 또는 보호 속성을 찾는 것을 의미했습니다.

언급한 두 게시물 모두 서명되지 않은 개인 상태에 문제가 있음을 나타냅니다. 그러한 문제에 대한 해결책에 대한 아이디어가 있습니까?

JavaScript의 내부 작동에 대한 이해가 없는 사람으로서 그렇게 하는 것은 매우 어렵습니다.

You'd have to somehow encode a "private key" into each lexical environment.

나는 이것이 무엇을 의미하는지 전혀 모른다. 무엇을 위한 것입니까? 하는 것이 불가능합니까?

You'd have to change the semantics of each and every property access (because any property access might result in a private field). Engines are highly optimized around the current property lookup semantics.

가시성을 켜는 단일 스위치가 성능에 상당한 영향을 미칠 정도로 고도로 최적화되어 있습니까?

Would for-in enumerate over these properties?

문맥에 따라 다를 것 같아요. 같은 클래스 내에서 그렇습니다. 그러나 이것은 private 사용하지 않는 이유가 아니라 구현 세부 사항이며 다른 언어에서 이미 이러한 질문에 답했을 것입니다.

Can someone shadow a private property with a normal property lower on the prototype chain? What about the reverse?

아마도 첫 번째 질문에는 예(가시성이 증가함)이고 두 번째 질문에는 아니오일 것입니다. 다시 말하지만, 이것은 모두 이전에 수행된 것입니다. 그렇지 않습니까?

How do you prevent leaking the names of private fields to clients that shouldn't know that information? This is probably a fatal information leak.

가시성은 공개 인터페이스를 캡슐화하고 정의하기 위한 도구일 뿐입니다. 개발자의 99%는 아마도 "정보 유출"에 대해 신경 쓰지 않을 것입니다. 즉, 여기에서 두 가지 개별 기능을 제안

All of this runtime stuff is going to be terrible for performance

성능을 원하면 "숨김/보안 상태"를 사용하십시오. :D 진지하게 말하자면 어떤 유형의 성능 손실에 대해 이야기하고 있습니까? 누군가 프로토타입을 만들 수도 있습니다. =)

Also, we couldn't use such a solution to self-host the built-ins

자체 호스팅 내장 기능(이것이 의미하는 바를 이해하고 있다면)이 성능에 정말 좋지 않습니까? 그렇지 않은 경우 ... "숨겨진/보안 상태"를 사용하고 상위 수준의 개인/보호된 가시성을 사용하지 마십시오.

조회 체인을 복잡하게 만드는 것은 호환성 측면에서 위험할 것이라고 생각합니다.

이것이 작동할 수 있는 방법이라고 생각하는 최초의/유일한 사람이 아닙니다. 속성에 액세스하면 가시성을 위해 설명자를 찾고 그에 따라 응답합니다. JS에서 실제로 어떻게 작동하는지 모른다면 복잡해 보이지 않습니다. JS 내부/속성 조회 알고리즘에 대한 단기 과정을 정말 읽어야 합니다. =피

Ruby는 sigil--@이 있는 private state의 좋은 예라고 생각합니다.

Ruby는 C 계열 언어도 아니며 공개 필드도 없고 getter와 setter(접근자)만 있습니다. 현재 비공개 상태 제안에는 동일한 범용(속성 선언)을 사용하여 나란히 여러 선언이 있지만 시각적으로 다르고 일관성이 없는 구문이 있습니다.

그렇긴 해도, 나는 여기서 내 깊이를 벗어났고, 가치보다 노이즈를 더 많이 추가할 가능성이 높으므로 조용히 하고 전문가들이 합의에 이르도록 하려고 합니다.

나는 이 희망에 대해 TC39와 논의하고 접두사를 피하는 방법에 대한 다른 아이디어를 생각해낼 수 있는지 알아보겠습니다. 저는 개인적으로 가지고 있지 않습니다. TypeScript가 개인 필드를 구현하기로 결정한 경우에도 여전히 TC39의 1단계에 있으므로 변경될 수 있습니다.

TypeScript 팀은 구문과 기호/문자 접두사의 사용에 대해 어떻게 생각합니까?

개인적으로 무섭게 생겼다는 생각이...

참고 저는 # 구문을 제거하기 위한 제안 을 했습니다.

@shelby3 불행히도, 나는 그것을 현실적인 옵션으로 보지 않습니다. tl;dr, 우리는 모든 것이 eval 와 상호 작용하는 방식에 대해 걱정해야 합니다. sigil을 포함하지 않으면 모든 것이 "너무 역동적"으로 작동하여 제대로 작동하지 않습니다.

@littledan 나는 지금 거기에 따라 sigil 사용에 대한 나의 가장 강력한 주장 과 TypeScript와의 호환성 을 했습니다 . 메서드의 형식화되지 않은 인수에 대해 개인 정보를 선언해야 하는 이유를 이제 이해합니다.

@isiahmeadows

현재의 유사 비공개 구현을 대부분 대체할 것입니다. [...] 또한, 제안의 가장 중요한 부분은 비공개 속성이 클래스 자체 내에서만 사용할 수 있다는 것입니다.

의사 비공개 구현을 대체하지 않기를 바랍니다. 난 단지 클래스 내에서 가용성이 실제로 (이용하면 평균 접근성에 의해 주어진) 그런 좋은 일이 아니라고 생각. 예를 들어 보안 목적으로 엄격하게 개인적이고 접근할 수 없는 속성을 갖는 것이 합리적인 특별한 상황이 있을 수 있음을 인정합니다. 다른 언어에 익숙한 사람들에게는 private 가 실제로 JavaScript에서 비공개가 아니라는 것이 분명히 혼란스럽다는 것도 인정합니다. 그러나 보안상의 이유와는 별도로 대부분의 개발자는 대부분의 경우 private 계약을 정의할 때만 사용하고 액세스 가능성을 제어 하지 않아야 합니다.

예를 들어 건축가의 관점에서 TS private -keyword 및 유사 비공개 특성에 대해 매우 좋은 점은 다음과 같습니다.

• 유형 인터페이스의 계약과 클라이언트가 사용하는 방법을 표현할 수 있습니다.
• TS 컴파일러가 컴파일 타임에 계약을 확인합니다.
• 특히 화이트박스 단위 테스트의 경우 런타임에 계약을 의식적으로 "위반"할 수 있습니다.

런타임 시 private 속성에 대한 액세스 가능성은 테스트 중인 클래스에 private 필드를 설정하는 것만으로 private state를 주입할 수 있기 때문에 any 리팩토링 지원), 예:

let instance: ClassUnderTest = new ClassUnderTest();
instance["_privateField"] = "My injected state";

특정(비공개) 상태의 클래스를 설정하기 위해 복잡한 테스트 코드가 필요하지 않습니다.
pseudo-private 속성의 또 다른 장점은 원숭이 패치에 필수적이라는 것입니다.

@about-code https://github.com/tc39/proposal-private-fields/issues/33 참조

TypeScript 커뮤니티가 모든 private variable 행을 private #variable 기꺼이 변경할 것이라고 생각하지 않습니다.

TypeScript의 관점에서 볼 때 우리 대부분은 좋은 언어(intellisense, 빌드 시간 오류, 유형, 다양한 설탕)에 대한 사랑스럽고 달콤한 환상에 만족합니다. 이러한 환상은 우리에게 더 나은 개발 경험을 제공하고 더 나은 코드를 더 빨리 작성합니다. 이것이 우리가 ESNext 트랜스필레이션 외에 TS를 사용하는 주된 이유입니다. 그러나 후자의 경우 Babel이 있고 그게 더 좋습니다(또는 적어도 내가 마지막으로 확인했을 때 더 좋았습니다).

나는 실제로 소스 파일의 구문 설탕보다 개인 변수에서 더 많은 것을 원하는 소수에 대해 말하는 것이 아닙니다. 나는 그 사람들에게 더 강력한 것이 필요하다고 생각합니다. 아마도 네이티브 코드에 더 가깝습니다.

하지만 나머지는 JS private이 필요하지 않습니다. C++, Java, C# 등에서 사용했던 것처럼 간단하고 쉬운 private convenient 변수가 필요합니다.

우리에게 고통이 되지 않는 해결책에 투표해 주십시오. 아마 소프트 프라이빗? 우리가 sigil private #variable 을 원하는지 의심스럽기 때문입니다. 아니면 TS private 와 ES private이 다른 개념일까요? 못생긴.

@igabesz

TypeScript 커뮤니티가 모든 private variable 행을 private #variable 기꺼이 변경할 것이라고 생각하지 않습니다.

사실 그 제안으로 private 는 불필요할 것입니다. 대신 # sigil은 충돌 없이 완전히 대체합니다.

하지만 나머지는 JS private이 필요하지 않습니다. C++, Java, C# 등에서 사용했던 것처럼 간단하고 쉬운 개인용 편리한 변수가 필요합니다.

TypeScript의 private은 대부분의 OO 언어와 마찬가지로 soft private입니다. Java의 private 변수조차도 여전히 기술적으로 soft-private입니다. 왜냐하면 그것들은 여전히 ​​탈출 해치로 접근할 수 있기 때문입니다. JS private은 this 가 아닌 인스턴스의 private 상태에 계속 액세스할 수 있다는 점을 제외하고 클로저를 사용하는 것과 같습니다.

우리에게 고통이 되지 않는 해결책에 투표해 주십시오. 아마 소프트 프라이빗? 우리가 sigil private #변수를 원하는지 의심스럽기 때문입니다. 아니면 TS private과 ES private이 다른 개념일까요? 못생긴.

그것들은 다른 개념이지만 일반적으로 탈출용 해치는 실제로 거의 유용하지 않습니다. 주요 예외는 객체 검사(예: 개발자 도구, Node.js util.inspect )이지만 대부분은 호스트 정의이며 현재 이미 권한 있는 기본 API를 사용하므로 사양에 추가할 필요가 없습니다.

또한 ES가 비공개 상태를 표준화하면 TS는 이를 채택하고 다음 메이저 버전에서 제거될 자체 소프트 비공개 메커니즘을 더 이상 사용하지 않을 것입니다. 항상 ES의 엄격한 상위 집합이었으며 ES 자체가 진화함에 따라 필요한 만큼 기능을 추가(비동기 함수), 변경(클래스) 및/또는 사용하지 않음( /// <amd-dependency /> )하여 엄격한 ES로 유지됩니다. 상위 집합이며 현재 사양을 복제하지 않습니다.

또한 ES가 비공개 상태를 표준화하면 TS는 이를 채택하고 다음 메이저 버전에서 제거될 자체 소프트 비공개 메커니즘을 더 이상 사용하지 않을 것입니다.

😭

또한 ES가 비공개 상태를 표준화하면 TS는 이를 채택하고 다음 메이저 버전에서 제거될 자체 소프트 비공개 메커니즘을 더 이상 사용하지 않을 것입니다.

이것은 TS 팀의 입장이 아닙니다. 우리는 조만간 어떤 것을 더 이상 사용하지 않을 계획입니다.
비공개 상태 제안이 올바른 상태에 도달하면 TS가 이를 구현합니다. 나는 이것이 오늘날 TS가 구현하기 때문에 이것이 private에 어떤 의미도 있다고 생각하지 않습니다.

@mhegazy 알겠습니다. 정정합니다. (그것은 교육받은 추측이었습니다, BTW.)

클래스 필드 제안 이 현재 2단계에 있으므로 TypeScript 팀이 이를 고려하고 EcmaScript 표준을 따를 준비가 되어 기쁩니다 💯

비공개 상태 제안이 올바른 상태에 도달하면 TS가 이를 구현합니다.

@mhegazy 3단계가 구현하기에 적절한 시기입니까?

편집: 내 대답 을 찾았을 수도 있습니다 😄

@styfle 은 구현과 관련된 현재 고려 사항을 논의하는 디자인 회의 노트(#16415)의 토론을 참조하세요.

3단계가 시행하기에 적절한 시기입니까?

예. 우리는 이 기능에 가능한 다양한 디자인을 조사하기 시작했습니다.

클래스 필드 제안은 현재 3단계 입니다. (한 달 전 기준)

클래스 필드 제안은 현재 3단계 입니다. (한 달 전 기준)

클래스 필드가 Stage 3에 도달하는 동안 Private Methods 및 Accessors는 그 이후로 Stage 2에 있었고 어제까지 Stage 3으로 옮겨졌습니다. 이제 클래스의 private 멤버를 처리하는 데 필요한 모든 것이 Stage 3에 있습니다.

#[field] 구문 채택에 대한 TS 팀의 입장/진행 상황에 대한 업데이트가 잠시 동안 3단계에 있었습니까? 개인적으로 나는 그것을 정말로 싫어하고 TS의 기존 private 키워드를 훨씬 선호하지만 동시에 가능한 한 표준에 가깝고 싶습니다.

개인적으로 너무 싫고 TS의 기존 private 키워드를 훨씬 선호합니다.

나도 너무 못생겼어

하지만 @mhegazy 나는 이것을 (시도)하고 싶습니다. 할 수 있습니까?

구문 분석은 나쁘지 않아야 하지만(거의 토큰에 불과한 거의 새로운 수정자) 유형 검사는 고통스러울 것입니다(어떻게든 비교해야 하는 두 가지 다른 종류의 private가 있기 때문에). downlevel 방출은 끔찍 합니다(실제 런타임 개인 정보 보호 수준을 @rbuckton 에는 이에 대한 아이디어가 있고 아마도 구현이 있을 수 있습니다(확실하지 않지만 그는 포크에 많은 것을 가지고 있습니다). 우리는 기술적으로 당신이 시도하는 것을 막을 수는 없지만, 당신이 시도하고 싶은 다른 것을 찾을 수 있다면 그것을 추천하지 않을 것이며, 나는 당신이 그것을 마치면 그것을 받아들일 준비가 될 것이라고 보장할 수 없습니다. 또한 private 필드와 메서드가 발전했지만 private statics (및 아마도 데코레이터 )도 발전할 때까지는 여전히 약간 불완전합니다(모두 상호 작용하는 방식을 고려할 때 한 번에 모두 추가하는 것이 더 나을 수 있음).

여기 많이 있습니다.

@weswigham 알았어 포기 😂

다음은 내가 ( @Neuroboy23 및 기타 사람들과 함께) 개인 필드 구현을 실험할 것이라는

업데이트: 진행 중인 작업이 여기에 있습니다 .

예. 우리는 이 기능에 가능한 다양한 디자인을 조사하기 시작했습니다.

나도 # 구문을 좋아하지 않지만 이 구문 뒤에 있는 기술적인 이유를 이해합니다. @mhegazy TypeScript가 namespace , private 와 같은 구식 구현으로 무엇을 할 것인지 생각하는 새로운 제안을 구현한 후 TypeScript 팀이 실제로 하고 싶은 것은 동일하거나 거의 동일하게 수행하는 더 나은 es-standard 방법이 있기 때문이 아닙니다.

또한 protected 대한 몇 센트를 추가하고 싶습니다. (지금 희망적으로) 언젠가 private 키워드를 제거/사용 중단하려는 경우 protected 키워드로 동일한 작업을 수행하는 것이 괜찮다고 생각합니다. 나는 대부분의 사람들이 동의하지 않을 수 있다는 것을 알고 있지만, 예, 추가 가시성 범위가 때때로 편리할 수 있지만, 그것의 전반적인 가치는 그다지 높지 않습니다.

@pleerock ,

이것이 내가 TypeScript에서 볼 것으로 기대하는 것입니다.

class Example {
    private a = 1;
    #b = 2;
}

방출(ESNext 대상):

class Example {
    a = 1;
    #b = 2;
}

방출(ESNext를 대상으로 하고 ES 개인 필드로 개인으로 표시된 필드를 방출하는 새로운 컴파일러 옵션 사용):

class Example {
    #a = 1;
    #b = 2;
}

이는 이전 버전과 호환되어야 하며 깨끗한 구문으로 ES 개인 필드를 사용할 수 있어야 합니다.

@glen-84 당연히 그렇겠죠. 저는 구식 키워드와 구문에 대한 장기 계획에 대해 이야기하고 있었습니다.

구문이나 키워드를 더 이상 사용하지 않을 계획입니다.

또한 private 를 # 로 변환하는 옵션이 없을 것이라고 생각합니다. 예상되는 동작이 다릅니다. # 는 하드 런타임 개인 정보 보호이며 private 는 디자인 시간 개인 정보 보호입니다.

@weswigham 저도 그렇게 생각합니다. @RyanCavanaugh 예, 예상된 답변이었습니다. 그러나 여전히 나는 최신 ecmascript 제안으로 인해 쓸모 없게 되었기 때문에 새로운 사용자가 네임스페이스/비공개 키워드를 사용하는 것을 피하기 위해 최소한 몇 가지 전략을 적용할 것입니다.

사람들은 일반적으로 우리가 물론 업데이트하는 문서 읽기를 기반으로 이것을 알아냅니다. module foo { 는 여전히 언어에 있지만 namespace foo { 이전의 아주 오래된 코드베이스를 제외하고는 기본적으로 더 이상 야생에서 볼 수 없습니다.

@RyanCavanaugh 잘 들었습니다. 그러나 여전히 나는 C#에서 오는 새로운 사람들이 확실히 네임스페이스(전부는 아니지만 일부)를 사용하려고 할 것이라고 믿습니다. 다른 언어에서 온 사용자도 마찬가지일 것입니다. # 대신 private를 사용하기 시작하고 네임스페이스가 있는 예제보다 더 많은 경향이 있습니다.

또한 private를 #로 변환하는 옵션이 없을 것이라고 생각합니다. 예상되는 동작이 다릅니다. #은 하드 런타임 개인 정보 보호이며 private은 디자인 시간 개인 정보입니다.

도오. 나는 우리가 ... 불행한 구문을 피하기 위해 엄격한 개인 정보 보호를 위해 선택적으로 private 를 사용할 수 있기를 바랐습니다.

어쨌든 soft-private는 내 (현재) 사용 사례에 충분할 것입니다.

이 기능이 거대하고 버전 3이 사람들이 새로운 # 구문을 사용하기 시작하도록 하는 좋은 기회로 보이기 때문에 앞으로 나올 TypeScript 3 버전에 이 구문 지원을 포함하는 것이 좋을 것이라고 생각합니다.

편집: 버전 3이 이미 출시되었다는 사실을 잊어버렸습니다.

참고로, 최근 TC39 제안서의 리포지토리에 개인 필드/슬롯/무엇이든 간에 약간의 변동이 있으므로 현재 형식의 제안이 성공할지는 확실하지 않습니다. 다음은 몇 가지 관련 문제입니다.

• https://github.com/tc39/proposal-class-fields/issues/100
• https://github.com/tc39/proposal-class-fields/issues/106

저는 TC39는 아니지만 모든 사람에게 개인적으로 제안하는 것은 먼저 구문이 다시 굳을 때까지 기다린 다음( 4단계까지 기다릴 수 있음) 구현하는 것입니다.

FWIW 나는 tc39/proposal-class-fields#100의 논의를 특정한 것을 나타내는 것으로 해석하지 않을 것입니다. # 는 처음에는 낯설지만 선호되는 구문 형식은 제안되지 않았으며 사람들이 원하는 유일한 구문은 분명히 작동하지 않는 것 같습니다. 일종의 접두사 sigil이 있어야 하며 this.someProp 를 비공개로 허용하려는 모든 시도는 실패할 운명입니다.

나는 그것이 오히려 무시하는 것처럼 들리지만 솔직히 그것이 내 의도라는 것을 알고 있습니다. 해당 스레드의 불만 제기자 중 누구도 기존 스레드 또는 FAQ에서 해결된 핵심 기술 문제에 의미 있게 관여하지 않았습니다. 해당 리포지토리의 스레드를 읽고 왜 sigil이 필요한지에 대한 길고 정확한 설명을 보는 것은 우울합니다.

엄격한 런타임 개인 정보 보호가 정말로 필요하지 않는 한 아무도 개인 필드를 사용하지 않는 것이 최종 목표인 경우 성능 및 디버깅 가능성 측면에서 웹에 좋은 결과일 수 있습니다.

나는 그것이 언급하기에 이상적인 문제가 아닐 수도 있다는 데 동의하지만, 다른 하나는,
tc39/proposal-class-fields#106, 아마도 훨씬 더 암시적일 것입니다.
다른 무엇보다도 약한 맵을 사용하는 것에 대한 진지한 토론
프록시 interop은 분명히 짜증납니다.

이사아 메도우즈
[email protected]
www.isiahmeadows.com

2018년 7월 30일 월요일 오후 3:38 Ryan Cavanaugh 알림 @github.com
썼다:

FWIW 나는 토론을 해석하지 않을 것입니다
tc39/proposal-class-fields#100
https://github.com/tc39/proposal-class-fields/issues/100 예정
특히 어떤 것을 나타냅니다. # 처음에는 얼굴이 붉어지는게 예쁘지 않지만
선호되는 구문 형식은 제안되지 않았으며 유일한 구문은
사람들이 원하는 것처럼 보이는 것은 분명히 실행 가능하지 않습니다. 접두사가 있어야 합니다
일종의 인장과 this.someProp을 비공개로 허용하려는 모든 시도
실패할 운명입니다.

나는 그것이 오히려 무시하는 것처럼 들리지만 솔직히 그것이 내 의도입니다-
해당 스레드의 불만 제기자 중 누구도
현존하는 쓰레드나 FAQ에서 다루는 핵심 기술 문제. 이것의
그 리포지토리의 스레드를 읽고 긴 시간을 보려면 정말 우울합니다.
인장이 필요한 이유에 대한 올바른 설명은
지면.

최종 게임이 정말로 개인 필드를 사용하지 않는 한 아무도 개인 필드를 사용하지 않는다는 것이라면
엄격한 런타임 개인 정보 보호가 필요합니다. 이는 아마도 웹에서 좋은 결과일 것입니다.
성능 및 디버깅 가능성 측면에서.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/Microsoft/TypeScript/issues/9950#issuecomment-408984395 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AERrBGCphyQUu5lJQW7lgsqALLL3e0_Wks5uL2DLgaJpZM4JVDwV
.

WeakMaps 사용에 대한 논의가 있지만 Proxy와의 상호 작용이 어떻게 향상되는지는 알 수 없습니다. 비공개 수업 기능이 어떻게 작동하여 피드백을 위해 위원회에 제출해야 하는지에 대해 다른 아이디어가 있는 TC39 회원을 초대하고 싶습니다. 현재 이 제안은 3단계에 있으며 이론적으로 위원회의 합의된 입장을 나타냅니다. 다른 디자인이 가능하더라도 많은 사람들이 이 기능을 활성화한다는 공통 목표를 달성하기 위해 타협했습니다.

저는 Proxy를 사용하여 개체 돌연변이를 관찰하는 방법과 이것이 개인 필드와 상호 작용하는 방법에 대한 프레임워크 간의 토론을 구성하기 위해 노력하고 있습니다. 대화에 참여하고 싶다면 알려주십시오.

@RyanCavanaugh

FWIW 저는 tc39/proposal-class-fields#100 의 토론을 특정 항목을 나타내는 것으로 해석하지 않습니다. # 는 처음에는 낯설지만 선호되는 구문 형식은 제안되지 않았으며 사람들이 원하는 유일한 구문은 분명히 작동하지 않는 것 같습니다. 일종의 접두사 sigil이 있어야 하며 this.someProp 를 비공개로 허용하려는 모든 시도는 실패할 운명입니다.

늦었지만 실제로 this->var 구문 제안이 있습니다 .

물론 이 제안은 죽었을 가능성이 큽니다("위원회가 열광하지 않았다"는 것이 내가 찾을 수 있었던 유일한 이유입니다). 그러나 대체 구문이 실제로 제안되었으며 모든 이해 당사자가 이에 대해 잘 알고 있기를 바랍니다.

런타임에 적용되는 일종의 _soft_ private로 private 변환하는 컴파일러 옵션이 있으면 좋을 것 같습니다. 나는 진정한 hard private을 필요로 하는 유스 케이스가 특히 일반적이라고 생각하지 않습니다. 그래서 # 구문을 싫어하더라도 대부분의 사람들은 private 를 고수하는 경향이 있다고 생각합니다. 그러나 컴파일 시간 전용은 _너무_ soft IMO입니다. 또한 이러한 옵션은 가능한 private 변형의 수를 줄이는 데 도움이 될 것입니다. 개발자가 직접 구현해야 하는 경우 다음을 모두 가질 수 있습니다.

class Demo {
  private a

  #b

  <strong i="9">@reflect</strong>
  #c
}

그래서 저는 새로운 옵션이 활성화되면 private a 가 <strong i="13">@reflect</strong> #a 변환될 것이라고 제안합니다. 여기서 @reflect 는 커뮤니티 지원 API를 통해 속성을 반영할 수 있는 데코레이터입니다. 표준 데코레이터 라이브러리에 대한 이야기 가 있었습니다. 그래서 @reflect 데코레이터(또는 우리가 부르고 싶은 것은 무엇이든)는 미래에 표준화될 수 있습니다. 그런 면에서 좋은 후보라고 생각합니다.

내 제안의 주요 단점은 성능에 영향을 미칠 것이라고 생각합니다. 언젠가 JS에 최적화를 위해 기본적으로 구현되는 표준 데코레이터가 있을 수 있기를 바랄 수 있지만 가까운 미래에 대한 현실은 <strong i="19">@reflect</strong> #x 가 #x 보다 느릴 것입니다. 그러나 나는 이것을 옵션으로 제안할 뿐이며 기본적으로 비활성화되어야 합니다(이전 버전과의 호환성을 위해).

@MichaelTheriot

늦었지만 실제로 this->var 구문을 제안하는 제안이 있습니다.

물론, 이 제안은 죽었을 가능성이 높습니다("위원회가 열광하지 않았습니다"가 내가 찾을 수 있었던 유일한 이유임).

위원회는 예를 들어 https://github.com/tc39/proposal-class-fields/issues/100#issuecomment -429460917과 같이 클래스 1.1 제안 대신 현재 제안을 지지하는 충분한 이유를 제시했습니다.

@mbrowne

놓쳤을 수도 있습니다. 클래스 1.1의 이슈 페이지는 반년 동안 비활성화되었고 링크 된 예제조차도 내 의견보다 한 달 후에 작성되었습니다.

참고로, 몇 달 전에 링크한 스레드에서 이것을 언급했습니다 . 여기에 내 의견은 대체 구문이 제안되지 않았다는 오해를 해결하기 위한 것입니다. 관련된 모든 당사자는 그렇지 않다는 사실을 알아야 한다고 생각하기 때문입니다.

편집 : 내 의견은 TypeScript가 다른 것을 제안하지 않습니다. 제안서의 참조된 문제에 대한 잘못된 정보를 수정하는 것이 유용하다고 생각합니다.

@MichaelTheriot 대안 제안을 알려야 하는 당사자는 이 대화에 관련된 당사자가 아닙니다. TypeScript는 비준을 위해 진행 중인 제안을 따를 것입니다. 대체 구문이 제안되었지만 채택되지 않았다는 사실은 내 생각에 이 대화에 실제로 유용하지 않습니다.

여러분, 도움이 될 수 있도록 런타임 보호/비공개 멤버의 구현을 공유하고 싶습니다.

lowclass 참조하십시오.

런타임 public/protected/private 멤버의 모든 종류의 사용을 보여주는 광범위한 테스트 파일을 확인하십시오. 구현은 길지 않으며 최소한의 보호/개인 기능만 갖기 위해 일부 기능을 생략할 수 있습니다.

노트:

• WeakMaps를 사용하여 보호/개인 상태를 저장합니다.
• 내가 본 다른 구현과 달리 동기 호출 스택 추적에 의존하지 않기 때문에 callbacks/promises/await가 있는 비동기 코드에서 작동합니다.
• getter/setter(수퍼 호출 포함)와 함께 작동합니다(테스트 참조).
• 기본 super 또는 ES5용 Super 도우미를 사용하여 작동합니다(테스트 참조).
• constructor 방법을 지원합니다(테스트 참조).
• 기본 제공 클래스를 확장하는 기능(날짜 제외, 하지만 사람들이 불가능하다고 말하지만 확인하고 싶습니다. 기본 사용자 정의 요소로 작업하는 테스트 참조).
• 일반 기본 class es를 확장하는 기능(테스트 참조).
• 네이티브 class es를 래핑하여 보호 및 비공개 기능을 제공합니다(테스트 참조).
• 기본 class 대신 ES5 스타일 function 클래스를 작성합니다(테스트 참조).
• 성능 최적화를 위한 많은 여지(fe caching super/protected/private helper calls and optimizing lookup algos)

테스트를 실행하려면:

npm install
npm test

또한 Babel 구현에 대한 자세한 내용과 문제는 https://github.com/babel/proposals/issues/12 및 https://github.com/babel/babel/issues/8421 을 참조 하세요 .

안녕하세요 여러분,

아직 완료되지 않은 개인 클래스 필드 사양을 구현하지 마십시오. 문제가 있습니다.

이 스레드를 읽으십시오.

이 글을 읽는 모든 사람이 다른 구문 아이디어를 살펴보고(더 많은 정보가 있습니다) 의견을 말하도록 권장합니다.

fe 여기에 다른 스레드가 있습니다 (현재 # IMHO보다 더 나은 구문 아이디어가 있음).

이미 public/private/protected를 널리 사용하고 있는 JavaScript 커뮤니티가 있다면 TypeScript 커뮤니티는 JS private/protected의 미래를 형성하는 데 큰 도움이 될 것입니다.

그래서 private 클래스 필드는 V8 v7.2와 Chrome 72에서 제공되고 있습니다. private 필드 제안을 구현할 계획이 있습니까?

@ChrisBrownie55 공개 필드가 배송됩니다. 개인은 아닙니다.

@jhpratt 내 잘못이지만 Chrome 팀이 가까운 시일 내에 비공개로 배송할 계획인 것 같습니다.

참고: https://v8.dev/blog/v8-release-72#public -class-fields

V8 7.2부터 공개 클래스 필드를 제공하고 있다고 문서화하지만 개인 필드(강조 광산)에 대해서는 다음과 같이 설명합니다.

개인 클래스 필드에 대한 지원 은 향후 V8 릴리스에서 계획됩니다 .

@isiahmeadows 실제로 Google 개발자 블로그의 다른 게시물을 참조했습니다.

결론

공개 클래스 필드는 V8 v7.2 및 Chrome 72에서 제공됩니다. 비공개 클래스 필드는 곧 제공할 예정입니다.

Google 개발자 블로그의 기사 링크

이 기사는 @mathiasbynens 와 Andreas Haas가 작성했으며 필요한 경우 설명을 요청할 수 있습니다(각 게시물이 꽤 명확했다고 생각하지만). cc @gsathya 와 @joyeecheung 은 V8 구현의 마무리 작업을 하고 있습니다.

어쨌든, 2019년 1월 TC39 회의는 제안에 대한 합의를 다시 한 번 재확인하면서 민간 분야 및 방법 제안에 대한 대안을 재고하는 1년 반을 마감했습니다. 현재 버전이 안정적이고 TypeScript를 사용할 준비가 되었다고 생각할 수 있습니다.

Chrome에서 비공개 클래스 필드를 출시했습니다 🎉
현재 _canary_ 빌드로 출시된 Chrome 74에만 있습니다.

방금 Chrome 74에서 개인 클래스 필드를 제공했습니다! 지금 Chrome 카나리아에서 사용해 보세요!
— Twtiter를 통한 Sathya Gunasekaran

개인 클래스 필드에 대한 특정 구현(또는 구현)을 선택하는 데 있어 우리가 어디에 있는지 아는 사람이 있습니까? @trusktr 이 보았지만 "_Private Inheritance_"가 사양의 일부인지 모르겠습니다.

그것은 결정적으로 아닙니다. private 필드는 프로토타입 체인을 걷지 않습니다(다른 개체가 볼 수 있으므로 private가 아니므로).

개인 필드가 WeakMaps(필드당 하나의 WeakMap, Babel이 수행하는 것과 같은 방식)로 변환된다고 가정합니다. 또한 # 구문을 지원하는 브라우저를 독점적으로 대상으로 하는 사용자를 위해 최종 출력에

성능상의 이유로 개발자가 향후 호환성을 위해 # 구문을 사용할 수 있지만(더 많은 브라우저에서 지원하는 경우) 실제로 __ts# 와 같은 특정 접두사를 사용하여 공용 속성으로 변환할 수 있는 옵션을 고려할 가치가 있습니다 # 구문을 사용하는 개발자는 일반적으로 컴파일 타임과 런타임 프라이빗 모두를 예상하므로 기본적으로 꺼져 있어야 합니다. 그러나 런타임 성능을 최대화하고 그 동안 컴파일 시간 전용으로 만족하는 사람들에게는 잠재적으로 성능 저하를 일으키지 않고 새 구문을 사용하기 시작하는 좋은 방법이 될 수 있습니다.

구현 진행 상황에 대한 업데이트가 있습니까? 테스트하고 피드백을 제공하기 위해 구축할 수 있는 PR이 아닐까요?

@jhpratt 확실히! 이 PR 의 분기를 확인하면 프라이빗 이름의 인스턴스 필드를 테스트할 수 있습니다. 메서드 및 접근자가 진행 중입니다.

우리는 이 작업을 업스트림하기를 희망합니다. 이 사전 요구 사항 PR이 병합되는 즉시 이 리포지토리(Microsoft/TypeScript)에 대한 변경 사항을 PR할 수 있습니다: https://github.com/Microsoft/TypeScript/pull/30467.

피드백을 가장 환영합니다.

"개인 상속"이 사양의 일부인지 모르겠습니다.

Sidenote, 100% 진정한 개인 정보 보호를 가능하게 하기 위해 저급에서 해당 기능을 삭제할 계획입니다. 나는 실제로 그것을 필요로하지 않았습니다. 그것은 더 많은 실험이었습니다.

그건 그렇고, "개인 상속"에 대한 이론이 유용할 수 있는 경우를 대비하여 여기에 게시하고 싶습니다.

"비공개 상속"(현재 버전의 로우클래스에서 볼 수 있음)은 하위 클래스가 수퍼클래스에서 상속된 비공개 메서드를 사용할 수 있지만 해당 메서드가 해당 하위 클래스의 범위 내에서 인스턴스의 비공개 속성 에만 변경 사항을 적용한다는 것을 의미합니다. 하위 클래스에는 자체 정의에서 전용 메서드로 정의된 메서드가 있지만 하위 클래스는 상위 또는 형제 클래스 범위에서 인스턴스의 전용 속성을 수정할 수 없습니다.

이에 비해 "보호된 상속"에서 하위 클래스는 자체 인스턴스 또는 상위 클래스 인스턴스의 속성을 _can_ 수정할 수 있지만 여전히 형제 클래스의 속성을 수정할 수는 없습니다. 보호된 상속에서 하위 클래스는 모든 상위 클래스가 볼 수 있는 속성을 수정합니다(수퍼 클래스는 모두 동일한 속성에 대해 읽기/쓰기).

다시 말해서 "비공개 상속" 개념에서 각 클래스에는 비공개 범위가 있고 상속된 모든 비공개 메서드는 로컬 클래스 범위에서만 작동합니다. 반면 보호된 메서드는 전체 클래스 계층에 대한 단일 범위에서 작동합니다.

이것이 의미가 있는지 확실하지 않으므로 현재 ecma proposal-class-fields private field 기능을 사용하여 작성한 경우 "비공개 상속"이 무엇과 유사한지 설명하는 간단한 코드 예제가 있습니다.

Proposal-class-fields에는 "개인 상속"이 없으므로 다음은 작동하지 않습니다(진정한 개인 정보를 유지하기 위해 이것이 바람직하다는 데 동의합니다).

class Foo {
    test() {
        this.#privateMethod()
    }

    #foo = 'foo'

    #privateMethod() {
        console.log(this.#foo)
    }
}

class Bar extends Foo {
    test() {
        // This does not work, no private inheritance:
        this.#privateMethod()
    }

    // #foo is private only inside Bar code, it is NOT the same #foo as in Foo
    // scope.
    #foo = 'bar'
}

낮은 클래스에서 "비공개 상속"은 편집기에서 일부 복사/붙여넣기를 사용하여 동일한 것을 에뮬레이트하기 위해 다음과 같은 비 DRY 코드를 작성하는 것과 같습니다.

class Foo {
    test() {
        this.#privateMethod()
    }

    #foo = 'foo'

    #privateMethod() {
        console.log(this.#foo)
    }
}

class Bar extends Foo {
    test() {
        // This does not work, no private inheritance:
        this.#privateMethod()
    }

    // #foo is private only inside Bar code, it is NOT the same #foo as in Foo
    // scope.
    #foo = 'bar'

    // copy the method over by hand (because there's no private inheritance):
    #privateMethod() {
        console.log(this.#foo)
    }
}

두 예에서 #foo 변수는 각 클래스에 대한 특정 변수입니다. #foo 변수는 하나가 아니라 두 개입니다. 각각은 동일한 클래스 정의의 코드로만 읽고 쓸 수 있습니다.

상기 방법은 상기 방법이 사용되는 범위에서 동작 _but_ lowclass에서 개인 상속, 재사용 전용 수퍼 방법에있게 해준다. 따라서 위의 예와 같이 슈퍼클래스 메서드를 서브클래스에 복사하여 붙여넣은 것처럼 보이지만 여전히 각 클래스에 대해 두 개의 별도 #foo 변수가 있습니다.

로우클래스에서 슈퍼클래스에서 #someMethod 를 사용하면 슈퍼클래스의 #foo 에서 동작한다. 경우 #someMethod 서브 클래스의 범위에 사용되는, 그것은에서 작동 #foo 가 아닌 서브 클래스의 #foo 슈퍼 클래스의!

그것이 개념을 설명하기를 바랍니다. 그리고 그것이 사용되지 않더라도 어떤 종류의 아이디어를 촉발시키는 데 흥미롭거나 유용할 수 있기를 바랍니다.

이제 Chrome 안정적인 채널에 있으므로 개발자가 기본적으로 사용할 수 있습니다. 저는 대부분 VSCode 때문에 이 문제에 관심이 있습니다. 바닐라 .js 자바스크립트를 작성할 때 VSCode는 이를 오류로 표시합니다. VSCode에서 Vanilla JS의 private 클래스 필드에 대한 지원을 Typescript에 추가할지 여부에 대한 토론과 별도로 추가하는 방법이 있습니까?

개인적으로, 나는 TS가 4단계에 도달하기 전에 지원을 추가해야 한다고 생각하지 않습니다. TS는 이미 현재 충분히 잘 작동하는 비공개 컴파일 시간을 가지고 있습니다. 4단계에 도달한 후에는 그것이 의미가 있다는 데 동의할 것입니다. (토론에서 때때로 유동적인 상황이 발생했기 때문에 나는 여전히 그것이 황금 시간대에 준비되었다고 생각하지 않을 것입니다.)

업데이트: Node 12 안정 버전에서도 지원됩니다. 또한 Babel에는 이 구문을 변환하는 플러그인이 있습니다. 개발자는 종종 4단계 제안이 되기 전에 기능을 사용합니다. Vanilla JS(non-ts)에서 이 구문에 대한 지원이 추가되거나 jsconfig.json 통해 활성화하여 VSCode를 사용할 때 오류가 표시되지 않도록 하는 방법을 보고 싶습니다. VSCode 리포지토리는 JS 지원이 TypeScript에서 지원되며 이 문제를 언급했다고 말합니다.

TypeScript가 주요 브라우저와 Node.js의 프로덕션 환경에 이미 존재하기 때문에 이 기능을 전혀 지원하지 않는 것은 의미가 없다고 말해야 할 것입니다. 이것은 TypeScript가 지금 모든 것을 완전히 굳혀서 기본 기능으로 출시해야 한다는 말은 아닙니다.

TypeScript는 이 기능이 실험적이며 3단계와 4단계 사이에 변경될 수 있음을 나타내는 플래그 아래 개인 필드를 도입하는 것이 좋습니다.

의미 없이 구문 지원을 먼저 구현할 수 있을까요?

의미 없이 구문 지원을 먼저 구현할 수 있을까요?

유형 검사/인텔리센스의 경우 일종의 의미 체계가 있어야 한다고 생각하지만 BigInt 와 같은 하위 변환 지원은 할 수 없습니다( esnext 와 함께만 사용할 수 있음).

fwiw, 구현 피드백으로 인해 3단계에서만 변경될 수 있습니다. 크롬이 배송 중이라는 점을 감안할 때 어떤 변화도 거의 없을 것입니다.

@ChrisBrownie55 이 기능이 아직 구현되지 않았다는 것은 말이 되지 않습니다.

진행 중인 것 같습니다.
https://github.com/microsoft/TypeScript/pull/30829
(분명히 https://github.com/microsoft/TypeScript/pull/30467에서 기다리고 있습니다)

맞습니다. #30829는 리베이스 후 병합할 준비가 되었습니다. 우리가 하고 싶은 일부 기능 게이팅을 모듈화하여 private-named 메소드에서 폭파시킵니다.

여러분, 주요 브라우저가 기능을 구현했다고 해서(느낌을 확인하고 사용하는 등) 모든 사람이 그래야 하는 것은 아닙니다.

토론에서 가끔 유동적인 상황이 발생했기 때문에 여전히 황금 시간대에 사용할 준비가 되었다고 생각하지 않습니다.

@isiahmeadows가 언급했듯이 클래스 필드 제안은 논란이

• https://github.com/tc39/proposal-class-fields/issues/100
• https://github.com/tc39/proposal-class-fields/issues/150

내가 언어 구현자라면 이에 대해 걱정할 것이며 수천 명의 (알지 못하는) 개발자가 문제가 있는 프로덕션 코드의 기능.

Private 필드는 아마도 ES6 이후 도입된 모든 기능 중 가장 논란의 여지가 있을 것입니다. 언어를 구현하는 사람이 해당 기능을 확정하는 데 도움을 주기 전에 싫어함을 고려하는 것이 현명하다고 생각합니다.

@trusktr 논란의 여지가 있는 기능일 수도 있지만 개발자가 사용할지 여부는 도구가 아니라 개발자에게

노드에서도 배송되었습니다.

Node의 JS 엔진을 유지 관리하는 Chrome 릴리스의 부작용일 뿐입니다.

논란의 여지가 있는 기능일 수 있지만 개발자가 사용할지 여부는 도구가 아닌 개발자에게 맡겨야 합니다.

그것은 당신과 같은 개발자의 경우일 수 있습니다(어쩌면 당신은 단지 제품을 출시해야 하고 당신이 가지고 있는 모든 도구로 작업하게 될 것입니다. 사실 이것은 당신이 이와 관련하여 해야 하는 일이며 많은 고용된 개발자가 하는 일입니다).

또한 클래스 필드와 관련된 발 총에 대해 알지 못하고 제공된 도구를 사용하려고 시도하는 많은 개발자가 있습니다.

또한 언어 자체와 유지 관리 가능한 코드의 미래에 관심을 갖고 특정 실수를 취소하기에는 너무 늦기 전에 올바르게 발전하기를 바라는 개발자도 있습니다.

좋은 점은 새 개인 필드가 # 구문을 사용하기 때문에 private 키워드를 대안으로 사용하여 수정할 여지가 여전히 있다는 것입니다.

TS는 정말 표준을 100% 따라야 합니까? 우리는 위원회가 thisGlobal 또는 #privateLol 커뮤니티에 반대한다는 것을 이미 알고 있으므로 너무 늦기 전에 Google이 JavaScript에 대해 독점권이 없다고 말할 때입니까?

@TeoTN 비공개 필드는 Google이 아닙니다. 다른 모든 최신 표준과 마찬가지로 TC39를 통해 진행되었습니다.

명확성을 제공하는 데 도움이 되는 몇 가지 사항:

• 우리는 아직 완전히 구워지지 않은 ES 기능을 제공하기 위해 서두르지 않습니다(선택적 연결, null 병합, throw 식, 파이프라인 연산자, nameof 등 참조).
• 반대로, 승인된 ES 기능을 구현하고 제공하는 것은 선택 사항이 아닙니다.
• 어떤 것을 좋아하지 않는 많은 사람들은 어느 쪽이든 요인이 아닙니다.
• 개인 필드는 심각한 사용자 고통을 야기하는 추후 설계 변경(또는 취소) 없이 구현하는 것이 안전하다고 판단되는 경우 TS에 포함될 것입니다.

@RyanCavanaugh 설명과 모든 멋진 작업에 감사드립니다! 작은 제안: ES는 지속적으로 발전하고 있고 많은 기능이 작업 중입니다. 어떤 단계에서 - 4단계?라는 규칙을 갖는 것이 좋다고 생각합니다. 3단계? 아니면 그 사이 어딘가? - ES 기능은 포함할 수 있습니다. 그렇지 않으면 앞으로 다른 기능에 대해 이러한 종류의 논의가 계속해서 반복될 수 있습니다.

프라이빗 필드는 완전히 구워졌다고 합리적으로 말할 수 있습니다.

@kkimdev Stage 4는 여기까지입니다. 표준의 일부가 되었다는 의미입니다.

완전히 구워지지 않은 ES 기능

완전히 구운 ES 기능이 무엇인지 궁금합니다. 이 예에서 "완전히 구워졌다"는 것은 무엇을 의미합니까?

승인된 ES 기능 구현 및 배송은 선택 사항이 아닙니다.

이것은 TypeScript의 목표가 바닐라 JS보다 단순한 유형이라는 점을 고려하면 완전히 합리적입니다(따라서 namespace 와 같은 것은 현재 목표와 관련하여 잘못된 선택이었고 enum 도 논쟁의 여지가 있음).

TypeScript는 모든 주요 엔진이 지정된 기능을 만장일치로 제공할 때까지 기능을 제공하기를 기다리거나 기다리지 않음으로써 언어 사양이 흔들리는 커뮤니티를 돕거나 돕지 않을 수 있습니다.

TS 팀 구성원이 TC39에 있기 때문에 비효율적인 것 같습니다. 그래서 그들은 누군가가 처음에 기능을 출시하기 전에 이미 3단계인 기능에 대한 합의의 일부였습니다(이 기능이 포함됨).

나는 TypeScript의 디자인 결정이 그들이 제공하는 것에 대해 보수적이라는 것을 정말 중요하게 생각합니다. 많은 경우 개발자에게 안정성을 보장하기 위해 조금 더 기다리는 것이 합리적입니다. 저는 개인 필드와 관련된 정책 결정에 매우 만족했으며 이에 대해

이러한 언어 디자인 결정에 대해 논의할 수 있는 가장 좋은 장소는 제안 저장소, TC39 회의 및 이 작업에 전념하는 다른 컨텍스트에서일 것입니다. 우리는 @trusktr 과 함께 private 필드와 메소드 제안에 대해 광범위하게

궁극적으로 TC39는 언어 설계를 계속해야 하는 곳이며 TypeScript 저장소는 기능의 우선 순위 및 구현 세부 사항, 기능이 언제 필요한지 판단하는 것과 같은 다른 측면을 논의하는 곳이 될 수 있다고 생각합니다. 충분히 안정적으로 배송됩니다.

TypeScript Intellisense는 VS Code에서 JavaScript 구문 강조 표시를 강화하고 VS Code 리포지토리에서 찾은 두 가지 구문 강조 문제(Microsoft/vscode#72867 및 Microsoft/vscode#39703)를 여기로 리디렉션하므로 TypeScript로의 구현에 대해 설명합니다. 이것이 JavaScript 파일의 오류가 아닌 것이 멋질 것이라고 말함으로써 기여하겠습니다.

다른 언어에 대한 컴파일러가 구문을 지원할지 여부를 결정하는 과정에 있기 때문에 완벽하게 유효한 JavaScript는 VS Code에서 잘못된 것으로 표시됩니다. :-)

TypeScript가 이에 대한 결정을 내리기 전에 시간을 들이는 데는 문제가 없지만(사실 저는 그것을 지원합니다!), 이것은 쉽게 고칠 수 없는 방식으로 JavaScript 구문 강조 표시에 영향을 미치거나 로컬에서도 작동할 수 없습니다. 나는 안다) 구문 형광펜 문법 파일을 패치함으로써 패치할 것이 없기 때문에(AFAIK).

제가 TypeScript 팀에 있지는 않지만, 그들은 이것을 구현하기 위해 적극적으로 노력하고 있으며 이 시점에서 개인 필드가 지원될 것이라는 데는 의심의 여지가 없다고 생각합니다. https://github.com/microsoft/TypeScript/pull/30829를 참조

작업 중임을 확인할 수 있습니다. 우리는 TS 팀과 협력하고 있으며 현재 리베이스를 마무리하고 있습니다. TS(및 확장에 따라 Language Server)의 private-named 필드에 대한 기대가 높습니다.

https://github.com/microsoft/TypeScript/pull/30829 에서 이를 구현한 Bloomberg의 공동 작업자에게 큰 감사를 드립니다

안녕하세요. 이에 대한 별도의 문제를 만들고 싶다면 그렇게 말씀해 주십시오. 나는 근거가 발광을 위해 무엇을 학습에 관심이있어 특별한 #private PropertyDeclaration 을 주도하는 것이 이 문제 .

예를 들어 다음 선언이 생성됩니다.

// index.d.ts
declare class Foo {
    #private;
    // ...
}

...입력이 주어지면:

// index.ts
class Foo {
    #name: string;
}

나는 그것이 거기에 있어야 하는 이유를 먼저 이해하려고 노력하고 있지만, 선언 생성을 중심으로 도구를 만들고 있다는 점을 감안할 때 생략할 수도 있습니다.

나는 그것이 거기에 있어야 하는 이유를 먼저 이해하려고 노력하고 있지만, 선언 생성을 중심으로 도구를 만들고 있다는 점을 감안할 때 생략할 수도 있습니다.

private의 존재는 우리의 분석에서 클래스를 명목적으로 만들므로 선언 파일에서 이를 유지하는 것이 중요합니다. dts-downlevel 와 같은 사후 방출 선언 변환기 도구를 사용하여 어떤 방식으로든 이전 TS에 대한 개인 선언의 수준을 낮출 수 있습니까? (아직 #privates에 대한 하위 레벨이 있는지 모르겠습니다)

Wesley가 말한 것에 추가하려면: downlevel-dts 는 이전 버전의 TypeScript와의 호환성을 위해 #private를 private 수정자로 변환합니다.

private의 존재는 우리의 분석에서 클래스를 명목적으로 만들므로 선언 파일에서 이를 유지하는 것이 중요합니다.

클래스를 명목적으로 만드는 방법에 대해 자세히 설명할 수 있습니까? 🙂 여러 개인 속성 #foo 및 #bar 주어지면 여전히 하나의 특별한 #private 앰비언트 선언 #private 속성 선언으로 대체되기 때문입니다. #foo 및 #bar 이름을 보존했다면 더 잘 이해할 것입니다. 특히 LanguageService가 #private 속성이 사용되지 않는다고 불평한다는 점을 고려할 때 약간 이상합니다. 그것은 나에게 버그처럼 보입니다. 그러나 모든 상황에서 private 필드는 형식의 public 속성의 일부가 아니며 클래스 외부에서 액세스할 수 없습니다. 따라서 이론적으로 왜 그들이 선언의 일부가 되어야 하는지 알 수 없습니다. KeyOf 유형이 아니고 앰비언트 선언의 일부가 아닌 public 이외의 다른 액세스 수정자로 주석이 달린 필드 및 메서드와 동일한 원칙이 적용되어야 하지 않습니까?

Wesley가 말한 것에 추가하려면: downlevel-dts 는 TypeScript의 이전 버전과의 호환성을 위해 #private를 private 수정자로 변환합니다.

좋은 솔루션처럼 들립니다. 그러나 그렇게 하면 private 수정자를 제공하는 속성이 유형의 공용 속성의 일부가 아닌 경우 .d.ts 파일의 일부가 아닙니다. 저는 특히 가장 단순한 예제에서도 #private 라는 사용되지 않는 속성에 대한 진단을 생성하는 선언에 관심이 있습니다.

@wessberg 원치 않는 언어 서비스 경고로 발견한 버그를 보고했으며 아마도 솔루션을 구현할 수 있습니다.

다른 질문을 다시:

클래스를 명목적으로 만드는 방법에 대해 자세히 설명할 수 있습니까?

누군가 전에 그것에 대해 문제를 제기했습니다 .

이러한 경우에 명목상을 만드는 한 가지 이유는 클래스의 구현자가 private 필드 간에 숨겨진 불변성을 유지할 수 있기 때문입니다. 항상 정렬됨" 또는 "직경은 2 * 반경입니다."

또 다른 이유는 런타임에 "올바른 작업을 수행"할 방법이 없기 때문에 아래와 같은 코드가 유형 검사에 실패해야 한다는 것입니다.

class A {
    #foo = getFoo();
    bar = "bar";
    equals(other: A) {
        return this.#foo === other.#foo && this.bar === other.bar;
    }
}

new A().equals({ bar: "bar" }); // error: missing property '#foo'

안녕하세요 여러분, 우리가 #private 구문을 가지고 있다는 사실이 너무 기쁩니다! 그것은 굉장!

그러나 나는 우리가 다음과 같이 속기 구문(제안 참조)을 가지고 있지 않다는 것이 정말 부끄럽다는 것을 인정해야 합니다.

class Counter {
  #count = 0
  increment() {
    return #count++
  }
}

실험적 기능으로 속기 구문을 활성화하기 위해 typescript 플러그인이나 tsconfig 옵션을 개발할 수 있는지 궁금합니다.

불필요한 this. 반복을 피하기 위해 매끄러운 인체 공학적 개선을 위해 죽어 가고 있습니다. 제안서에서 언급한 바와 같이 약식 구문의 단점은 제가 걱정할 중요한 문제로 보이지 않습니다. 그래서 나는 확실히 내 자신의 프로젝트에서 "experimentalPrivateShorthand": true 또는 이와 유사한 것을 설정하게 되어 기쁩니다.

이것이 가능합니까? 아마도 불가능한 이유가 있습니까? 관련된 작업은 무엇입니까? 건배!

:웨이브:추격

@chase-moskal TypeScript는 ECMAScript 표준 이외의 유형을 제외하고는 구현하지 않습니다. 그 이유는 개인 필드와 데코레이터에서 알 수 있듯이 의미 체계를 변경하기 때문입니다.

@chase-moskal this 항상 입력하지 않는 가장 실용적인 방법은 솔직히 IDE에서 바로 가기를 지정하는 것입니다(예: F3). TS 파서 또는 Babel 파서를 분기하고 플러그인을 작성하여 많은 것이 가능하지만 모두 많은 작업이 필요하며 공식 도구와 동기화되지 않습니다. 귀하의 질문은 물론 공식 지원에 관한 것이라는 것을 알고 있습니다. 단지 제 생각을 공유할 것이라고 생각했습니다.

@jhpratt — 내가 힙한 상태를 유지하는 데 사용되는 타이프스크립트. 예전에 데코레이터와 화살표 기능을 제공했습니다! 적어도 지금보다는 babel과 경쟁적이었습니다.

솔직히 말해서, 나는 1년 전에 내 babel을 사용하는 상대방처럼 멋진 미니멀리즘 클래스를 작성할 수 없으며 babel에는 내가 갈망하는 모든 종소리와 휘파람이 있습니다!

@mbrowne — 가독성 만큼 중요한 것은 코드의 "쓰기 가능성"이 아니므로 키 누름 계산에 대해 걱정하지 마십시오. 내 요점은 자바 스크립트 this 반복이 너무 자주 불필요한 불필요한 혼란이라는 것입니다.

이제 가독성을 위해 이것을 생각해 보십시오. #private 구문이 약식으로 표시되면 this 가 표시될 때마다 공개 멤버 에 있습니다. 가독성!

어쨌든, 나는 typescript가 아직 private 메소드를 지원하지 않는다는 것을 발견했습니다.

그래서 이 모든 것은 더 많은 작업과 시간이 필요합니다. 분명히 블룸버그 사람들이

필드를 일치시키는 개인 메서드가 없으면 기다리기만 하면 됩니다(아무도 같은 클래스에서 미쳐버리지 않고 typescript-privates와 해시태그-privates를 혼합하지 않을 것이기 때문입니다!)

그래서, 여기에서 타이프스크립트를 현대화하는 것은 블룸버그 팀이고, 1년 전에도 babel을 위한 동일한 개인 정보 보호 기능에 참여했습니까? 그들은 신의 일을 하고 있는데 왜 그런지 궁금합니다! 그것을 유지! 건배!

:웨이브:추격

예, TypeScript는 몇 년 전에 데코레이터를 제공했습니다. 뭔지 맞춰봐? 의미가 변경되었습니다. 큰 시간입니다. 이제 TypeScript는 가까운 장래에 레거시 API를 지원하지 않고 있으며 제거하기로 결정할 때마다 엄청난 손상을 일으킬 것입니다. 화살표 함수는 ECMAScript 사양의 일부이므로 이를 불러오는 것은 전혀 관련이 없습니다.

TypeScript는 현재 3단계에 도달하기 전에 ECMAScript 제안을 구현하지 않습니다. 바로 여기에서 TS가 관심을 갖기 전에 약어를 가져와야 합니다.

예, TypeScript는 몇 년 전에 데코레이터를 제공했습니다. 뭔지 맞춰봐? 의미가 변경되었습니다. 큰 시간입니다.

우리는 이상적인 세상에 살고 있지 않으며 현재 몇 가지 기능이 필요합니다. 예를 들어 데코레이터 제안은 아직 2단계이지만 일부 대형 프로젝트(Angular)에서는 오랫동안 이를 적극적으로 사용하고 있습니다. 또 다른 예: ECMAScript는 실제 문제를 해결하는 데 유용한 클래스 멤버에 대해 protected 수정자를 지정하지 않습니다.

이제 TypeScript는 가까운 장래에 레거시 API를 지원하지 않고 있으며 제거하기로 결정할 때마다 엄청난 손상을 일으킬 것입니다.

다른 언어도 컴파일러 플래그 아래에 실험적 기능을 도입합니다.

TypeScript가 1단계 또는 2단계에서 각 제안을 구현해야 한다고 말하지는 않지만 TS에 대한 많은 흥미로운 제안이 막혔습니다. ECMAScript에는 이에 상응하는 것이 없기 때문입니다(예: https://github.com/microsoft/TypeScript/issues/2000).

@ikokostya TypeScript가 구현한 후 의미 체계가 변경된 경우의 예로 데코레이터를 사용하고 있었습니다. 이 속기가 "지금 당장 필요하다"는 말씀이신가요? 저를 믿으세요. 추가로 5명의 캐릭터를 관리할 수 있습니다. 그것이 당신에게 중요하다면 컴파일러를 자유롭게 포크할 수 있습니다.

TypeScript는 플래그 아래에서도 3단계 이전에 어떤 것도 구현하지 않는 것에 대해 확고합니다. 이것은 이전에 다양한 다른 문제에서 철저히 논의되었습니다.

빙글빙글 도는 것 외에는 아무것도 보이지 않으므로 주목할만한 일이 발생하지 않는 한 더 이상 응답하지 않겠습니다.

@jhpratt 내 요점은 속기에 관한 것이 아닙니다. 제 댓글을 끝까지 읽어주세요.

포크에 대한 제안은 절대적으로 관련이 없습니다.

모든 사람이 동의하는 것은 아니며 TC39 위원회의 모든 사람이 동의하는 것은 아닙니다. 이 속기는 코드를 더 읽기 쉽고 직관적으로 만들 수 있습니다. 이에 대해 많은 논의가 있었고 이러한 우려 때문에 단축 구문은 별도의 제안으로 옮겨졌습니다. (나만의 명확한 의견을 형성할 만큼 충분히 생각하지 않고 요약만 드리겠습니다.) 이 제안을 추진하고 싶다면 진행 방법은 TC39에 피드백을 제공하는 것입니다. TS를 유지 관리하고 3단계에 도달한 모든 제안을 구현하는 데 이미 많은 작업이 포함되어 있다고 확신합니다. 따라서 TC39에서 더 발전하지 않는 한 이것이 TS에 대해 고려되기를 상상하기 어렵습니다.

그러나 나는 우리가 속기 구문을 가지고 있지 않다는 것이 정말 부끄럽다는 것을 인정해야

그 속기는 # 사용할 수도 있는 파이프라인 제안과 호환되지 않으며 이미 2단계 제안이 되는 것으로 논의되었습니다. 이렇게 일찍 제안을 구현한 다음 획기적인 변경을 수행하는 것은 정말 의미가 없습니다. 이러한 초기 단계에서는 어떤 제안이 승리할지조차 알 수 없습니다.

호환되는 것으로 판명되더라도 접두사 # 연산자에 대한 몇 가지 추가 사용 사례를 생각할 수 있습니다. 이 연산자는 5개의 추가 문자를 입력하기 위한 약식보다 더 유용합니다.

... 특히 개인 필드에 대한 사용 사례의 상당 부분이 this 에 전혀 없는 경우(예: static isMe(obj) { try { obj.#x; return true; } catch { return false; } } , 한 가지 예를 들자면).

@phaux — 속기 대 파이프라인에 대한 정말 좋은 정보입니다. 감사합니다!

@jhpratt

TypeScript는 플래그 아래에서도 3단계 이전에 어떤 것도 구현하지 않는 것에 대해 확고합니다.

충분히 공평하지만 개인적 방법은 사실 3단계 이지만 아직 타이프스크립트 지원이 없다는

나는 블룸버그 팀이 1년 전 babel에서 했던 것처럼 타이프스크립트에서 신의 일을 계속하고 있다고 가정합니다(기도)? 그렇다면 정말 인내심을 갖고 쪼그려 앉아만 있으면 됩니다. :)

ecmascript 기능에 대해 babel 및 브라우저와 비교하여 훨씬 더 경쟁력이 있었던 typescript처럼 보이지만 이제는 실제로 너무 보수적입니다. 우리는 babel 과 chrome 이 모두 1년 전에 비공개 필드(플래그 없음)를 제공한 상황에 있습니다. 블룸버그가 우리를 구하러 왔다

저는 타이프스크립트와 babel 기능 집합 사이의 미묘한 차이가 불안합니다. 제 babel 친구들은 작년에 아름답게 매끄러운 코드를 작성해 왔지만 저는 여전히 여기에 타이프스크립트 패널티를 지불하고 있습니다. 그들은 저를 비웃고 있습니다!

나는 실험적인 플래그를 제공하는 데 사용되는 타이프스크립트가 마음에 들었습니다. 이를 통해 미래에 리팩토링의 위험을 감수할 의향이 있는 것을 결정할 수 있었습니다. 이제 타이프스크립트의 입장입니다. 개발자가 이러한 위험을 결정하도록 하는 것이 너무 위험한지, 그리고 그 타자기는 이제 내 유모입니까?

점점 더 멋진 기능이나 정적 유형을 선택할 수 있는 것 같습니다. 하지만 지금은 두 세계의 장점을 모두 가질 수 없기 때문에 내 안에 인지 부조화가 커지고 있습니다.

저는 여기서 역학이 정말 궁금합니다. 블룸버그가 빛나는 갑옷을 입은 기사처럼 나서지 않았다면 타이프스크립트가 스스로 도전하기까지 얼마나 걸렸을까요? 아니면 이것은 typescript 실험입니까: "만약 우리가 이러한 새로운 기능을 피한다면.. 커뮤니티가 우리를 위해 그것을 할 수 있기까지 얼마나 걸릴까요?", 하, 그것은 내가 궁금해하기에도 꽤 냉소적입니다! 아니면 오픈 소스에 대한 자금 지원과 지원을 위한 새로운 길을 모색하는 정말 멋진 자비로운 협업인데 예상보다 조금 더 느렸을까요? 아니면 타이프스크립트의 철학이 예전보다 훨씬 보수적이었습니까? 이 스펙트럼에서 우리는 어디에 있습니까?

3단계 기능을 구현하기 위해 typescript에 대역폭이 부족하거나 우선 순위가 부족한가요?

욕설을 퍼부어서 죄송합니다. 저는 여기에서 무례하거나 심각한 비난을 하려는 것이 아니라 외부인의 관점에서 생각을 던지는 것뿐입니다. 나는 단지 사용자이고 여기에서 더 잘 아는 사람들이 내가 그린 이 그림에 어떻게 반응할지 정말 궁금합니다. 흥미로운 토론입니다. 모두 감사합니다!

:웨이브:추격

나는 실험적인 플래그를 제공하는 데 사용되는 타이프스크립트가 마음에 들었습니다. 이를 통해 미래에 리팩토링의 위험을 감수할 의향이 있는 것을 결정할 수 있었습니다. 이제 타이프스크립트의 입장입니다. 개발자가 이러한 위험을 결정하도록 하는 것이 너무 위험한지, 그리고 그 타자기는 이제 내 유모입니까?

당신을 유모하는 것이 아닙니다. 제안의 의미가 변경될 때 불가피하게 유지 관리 부담이 될 기능을 구현하는 데 시간을 소비하고 싶지 않다는 것입니다. 그들은 TS 구현과 충돌할 때 변경된 의미를 조정하는 방법을 찾는 데 시간을 보내고 싶지 않습니다. 그들에게는 더 나은 일이 있습니다. 해결해야 할 유형 관련 문제는 여전히 산적하기 때문에 제한된 자원을 사용하고 유형 시스템 문제를 해결하는 것 외에 TC39의 작업을 수행하려고 하지 않는 것이 좋습니다.

개인 메소드 및 접근자에 관해서는: V8에서도 구현되지 않습니다. 클래스 메서드와 인스턴스 필드는 서로 다르며... 스위치를 켜서 지원하는 것은 아닙니다. 구현하는 데는 실제 시간이 필요하고 이미 있는 그대로의 작업으로 가득 차 있고 작은 팀입니다. 또한, 규칙은 제안이 3단계에 있어야 한다는 것만이 아닙니다. 또한 제안의 의미가 최종적이라는 확신을 갖고 싶다고 명시적으로 말합니다. 드물기는 하지만 의미 체계는 3단계에서 _can_ 변경됩니다. 이 기능은 합당한 이유 없이 V8에서 구현되지 않습니다. 그래도 오해하지 마세요. 저도 그 제안이 구현되는 것을 보고 싶고 빨리 사용하고 싶습니다. 그러나 초기 단계의 제안을 구현하는 것은 시간 낭비이며 TS 팀의 시간은 다른 곳에서 보내는 것이 좋습니다. _오늘_ 사용하고 싶은 2, 1, 0단계 제안이 셀 수 없이 많지만 아직 가질 수 없는 이유를 이해합니다. 친구야 참아.

또한 babel에서 사용할 수 있는 옵션을 선호하는 경우 babel을 독점적으로 사용하여 타이프스크립트를 변환할 수 있습니다.

@0kku — 철학적 문제라기 보다는 단지 대역폭/용량 문제라고 말씀하시는 것입니다 — 이제 버그 백로그가 3단계 기능의 구현보다 우선순위가 높지만 typescript의 초기 역사로 돌아가면 아마도 버그가 더 적었을 것입니다. , 그래서 실험적 구현에 용량을 할당하는 것이 더 쉬웠습니까? 나는 이 이론을 살 수 있고 우리의 응답은 기다리거나 기여해야 합니다

@ljharb — 오, 이제 매우 흥미롭습니다 — 실제로 그런 방식으로 typescript와 babel을 함께 실행할 수 있습니까? 두 세계의 최고를 달성하려면?

하지만 vscode ts 언어 서비스가 익숙하지 않은 구문(예: 개인 메서드)을 사용하지 않고 어떻게 작동하는지 알 수 없습니까? Intellisense가 부족하면 typescript의 가치 제안에서 너무 큰 덩어리가 생깁니다. Intellisense를 완전히 비활성화해야 하는 경우 전략은 시작이 아닙니다.

이것은 장기적으로 어떻게 고칠 수 있습니까? 각 실험 기능의 구문에 대해 특정 타이프스크립트 오류를 ​​구분하고 또한 타이프스크립트 프로젝트가 tsconfig 수준에서 이러한 특정 오류를 비활성화할 수 있다면 — babel 기능과 typescript 기능을 모두 활용할 수 있는 기회가 있을 것입니다. 동시에 - 정말 멋진 사람이고 모든 종류의 불만을 녹이는 사람입니다. 건배!

:웨이브:추격

@ljharb

또한 babel을 독점적으로 사용하여 타이프스크립트를 변환할 수 있습니다.

난 당신이 (다른 모든 것들의 종류하지만 휴가) 단지 개인 바벨을 사용하는 방법을 transpile과 함께 그 코드에 유형 검사 않는 유형 검사 과정을 설정할 수 있습니다 가정 tsc . (유형 검사를 통과한 후 빌드 스크립트는 Babel만 사용합니다.) 하지만 IDE에서 많은 구문 오류를 무시해야 합니다. 이는 대부분의 사람들에게 문제가 될 것이라고 생각합니다.

@chase-moskal @0kku가 말한 것이 일반적으로

우리가 실험적 기능에 뛰어들지 않는 이유가 궁금하다면 --useDefineForClassFields 엄청난 복잡성 clusterfoxtrot 를 참조하십시오. 우리는 다른 의미 체계를 가진 가능한 TC39 제안이 그럴듯하게 존재할 수 없다는 가정 하에 매우 일찍 클래스 속성 초기화를 구현했으며 우리는 매우 틀렸습니다.

데코레이터는 같은 배를 타는 경향이 있으며, 우리가 이전 의미 체계에 대한 지원을 완전히 중단할 수 있다고 생각한다면 깜짝 놀라게 될 것입니다. 여러 대기업이 이를 중심으로 잘 채택된 대규모 프레임워크를 구축했습니다. "플래그 이름이 experimental 했으므로 지난 5년 동안 지원되었던 이 기능이 언젠가는 갑자기 사라질 수도 있다는 것을 알고 있어야 합니다."라고 말할 수 있다는 것은 완전히 비현실적입니다.

그 모두를 위해 우리는 우리의 삶의 나머지 여기이 미묘하게 다른 코드 경로를 유지 붙어있을거야 기능, 그리고 짜증,하지만 트레이드 오프입니다 - 우리는 매우 유지 빌드 간 타이프에 최선을 다하고 있습니다 코드의 런타임 동작을 중단하지 않고 가능한 업데이트; 이 절충안은 사용자에게 유리할 때(예: 프로그램이 계속 작동하는 경우 ) 보이지 않지만 열성적인 기능 채택 측면에서 단점을 보다 쉽게 ​​볼 수 있습니다.

우리의 관점에서, 당신은 부주의에 대한 책임을 포기할 수 없는 것과 마찬가지로 버전 간 런타임 호환성을 부인할 수 없습니다.

우리는 또한 대규모 커뮤니티의 반발에도 불구하고 선택적 체인의 조기 채택을 보류했습니다. 누군가가 "글쎄, 그냥 깃발 뒤에 두십시오"라고 말할 때마다 내가 니켈을 가지고 있다면, 나는 이것을 보트에서 타이핑할 것입니다. 그러나 그것은 옳은 일이었습니다. 왜냐하면 우리는 (null)?.prop 생산했는지 추측해야 했고 null ( undefined 아님)를 절대적으로 추측했을 것이고 우리는' d 그것을 알아내기 위해 또 다른 지속적인 복잡성 부담을 안고 살아가야 합니다. 강한 실적 인은 아무도 가득 300 만 개 라인의 코드베이스에 붙어 앉아 없다는 사실을 거꾸로 여기가 ?. 그들이 그 생산에 의존하는 경우 사용이 null 때때로을 어떤 방식으로, 다른 undefined 동작으로 전환하는 방법도 알아보세요.

Bloomberg는 이 기능을 갖게 되어 매우 기뻤고 TypeScript에 기여하기를 열망했기 때문에 비공개 필드를 구현했습니다. 그들이 이 상황에 있지 않았다면 우리는 다른 모든 것과 마찬가지로 이 기능을 직접 구현했을 것입니다.

일반적으로 자바스크립트의 타임라인은 매우 길고, 현실적으로 2020년 구문을 사용하지 않고 2016년에 훌륭하고 인체공학적인 JS를 작성할 수 있는 것처럼 2024년 구문을 사용하지 않고도 2020년에 훌륭하고 인체공학적인 자바스크립트를 작성할 수 있다고 말하고 싶습니다. 아직 최종적으로 결정된 의미가 없는 구문을 사용할 수 없다는 이유로 차단된 사람은 없습니다. 그 시점에서 그것은 단지 상상의 프로그래밍입니다.

뿐만 아니라 현재 클래스 필드 제안 및 모든 세부 정보가 현재 형식으로 4단계에 도달할지 여부도 100% 확신할 수 없습니다(특히 지금은 제안을 완전히 폐기하고 대체하기 위해 선동하는 TC39 회원사가 있기 때문에) 다른 것으로). 나는 95%의 확실성을 추측하지만 일반적으로 3단계 제안을 구현하는 것조차 위험이 완전히 없는 것은 아닙니다. 다만 3단계 이후 추가 변경 가능성은 매우 낮아서 현재의 TS 정책이 좋은 방향이라고 생각합니다.

이제 [class fields] 제안을 완전히 폐기하고 다른 제안으로 대체하기 위해 선동하는 TC39 회원사가 있습니다.

흥미롭네요. 그 링크가 마음에 드시나요?

여기에 아이디어가 있습니다. 아마도 TS 팀은 플러그인 작성자에게 컴파일 시간과 언어 서버 프로토콜 인텔리센스 시간에 연결되는 명확한 API를 제공하기 위해 플러그인 시스템을 개선하는 데 시간을 할애할 수 있습니다. 이를 통해 제3자는 새로운 구문을 포함하여 원하는 실험적 기능을 구현하고 IDE 및 텍스트 편집기 내에서 여전히 작동하는 인텔리센스를 사용할 수 있습니다.

마지막으로 확인한 바에 따르면 ttypescript 는 tsconfig.json 에서 TypeScript 변환기를 프로그래밍 방식으로 구성하지 않는 유일한 방법이며 IDE의 인텔리센스에 연결되지 않으므로 타사에서 다음과 잘 통합되는 의미 있는 기능을 만들 수 있습니다. VS Code와 같은 기존 도구는 아직 없습니다. 우리는 ttypescript 로 전환하고 VS Code가 구문을 이해하지 못하고 오류를 발생시키는 동안 터미널 출력에 의존해야 하는 좋은 VS Code 경험을 포기하고 싶지 않습니다.

그러면 TypeScript는 안정적인 기능에 초점을 맞추고 제3자가 위험한 실험 기능을 만들거나 사용하도록 할 수 있습니다(Babel 생태계에서처럼 쉽습니다).

흥미롭네요. 그 링크가 마음에 드시나요?

https://github.com/microsoft/TypeScript/pull/30829#issuecomment -541338266

Babel 플러그인으로 할 수 있는 구문적 작업은 매우 제한적입니다. 기본적으로 파서는 이미 지원해야 합니다. 예를 들어 do 표현식 "플러그인"은 여전히 ​​Babel 자체의 핵심에 논리가 필요합니다. https://github.com/babel/babel/blob/master/packages/babel-parser/src/parser /expression.js#L991 커맨드라인 스위치와

개인 클래스 메서드 및 접근자에 대해 따를 수 있는 문제가 있습니까?

@RyanCavanaugh

이 두 가지 기능 모두에 대해 우리는 평생 동안 미묘하게 다른 두 개의 코드 경로를 유지해야 합니다.

이런 식으로 진행되어서는 안 되며 전체 커뮤니티에 피해를 줄 수 있다고 생각합니다. 데코레이터가 3단계에 도달하면 새 버전의 데코레이터로 업그레이드할 시간을 주는 것이 합리적이라고 생각합니다. 한동안 둘 다 지원될 수 있고 TypeScript 4+에서 하드 스위치를 만들고 레거시 데코레이터를 삭제할 수 있습니다. 나는 그들을 사용하지 않기 때문에 이전 데코레이터와 새 데코레이터의 차이점을 모릅니다(음, 실험적 기능). 그러나 제안이 그들의 요구를 충족시키지 못한다면 영향을 받는 프로젝트가 제안에 대해 작업해야 한다고 생각합니다. 모두에게 더 좋습니다. TypeScript는 레거시 및 실험 기능에 대한 전쟁을 일으키기에는 잘못된 곳입니다.

여기에 착륙한 것을 후회합니다 :/

@RyanCavanaugh

Babel 플러그인으로 할 수 있는 구문적 작업은 매우 제한적입니다. 기본적으로 파서는 이미 지원해야 합니다.

진실. 그러나 TypeScript와 비교하기 위해 Babel에서는 파서를 분기하고 babel.config.js 를 설정하여 사용자 정의 파서와 사용자 정의 구문 플러그인을 사용할 수 있습니다. 예, 많은 작업(특히 처음으로 새 구문을 추가하는 방법을 배우기)이지만 TS에 해당하는 옵션을 알지 못합니다. 물론 Babel에서는 기존 구문을 기반으로 변환 플러그인을 작성하는 것이 훨씬 쉽습니다. TypeScript에서 사용자 정의 옵션의 현재 상태가 어떤지 잘 모르겠지만 몇 년 전에 마지막으로 검토했을 때 전체를 분기하는 것 외에는 확장할 수 있는 옵션이 없는 것처럼 보였습니다.

이것을 시도하십시오 : https://github.com/dsherret/ts-morph

private IMO의 해시는 추하고 혼란스럽습니다. 달리 구현할 방법이 없기 때문에 시행하기 어렵습니다. TS와 같은 빌드 단계가 없습니다. 그 효과는 많은 사람들이 기본적으로 개인용이어야 한다고 가르침을 받았기 때문에 JS를 작성하는 '올바른' 방법이라고 생각하는 사람들과 함께 "하드 개인용"의 아주 약간의 이득을 위해 기호로 코드를 막는 것입니다.
특히 문제에 대해 명백한 불일치가 있는 경우 표준으로 밀어넣기 전에 더 많은 제안이 있어야 합니다.

@robot56 은 기본적으로 비공개 여야 합니다 . 그들은 모든 것이 리플렉션을 통해 접근할 수 있어야 한다고 배웠습니다 . 이는 사실 누구에게나 좋은 것이 아닙니다.

@ljharb 예, this.#x = this.#something(); 와 같은 것을 보고 클래스에서 선언을 했을 때 내 첫 번째 생각은 해시가 변수 자체와 별개라는 것이었습니다. 나는 그것이 수정자라고 결코 생각하지 않았을 것입니다. 대중을 위한 밑줄, 그것도 거꾸로 보인다. 이것은 TS와 실제로 관련이 없지만 성가신 욕설 일 것입니다.

예, 익숙해지면 새로운 것을 배우는 것이 적응이 될 수 있습니다. 저는 JS 커뮤니티가 계속해서 배울 것이라고 믿습니다!

(해시 는 변수 자체의 일부이며 this.#x 의 이름은 "x가 아니라 private"이지만 실제로는 해당 어휘 범위에서 고유한 값인 #x .)

예, 익숙해지면 새로운 것을 배우는 것이 적응이 될 수 있습니다. 저는 JS 커뮤니티가 계속해서 배울 것이라고 믿습니다!

당신이 그것을 표현하는 방식으로, 그것이 우리의 프로그래밍 지혜에 추가되는 것을 배우는 것처럼 들리지만, 이것은 암기해야 하는 JS의 또 다른 특징일 뿐입니다.:D