Typescript: 최종 클래스 지원(하위 클래스화 불가)

private 생성자가 있는 클래스는 확장할 수 없습니다. 대신 이것을 사용하는 것을 고려하십시오.

내가 기억한 바에 따르면 컴파일러가 생성자의 private 키워드를 좋아하지 않는다고 확신했습니다. 붙여 넣기 버전을 사용하지 않을 수도 있지만

이것은 새로운 기능이며 TS 2.0에서 출시될 예정이지만 typescript@next 사용하여 사용해 볼 수 있습니다. 자세한 내용은 https://github.com/Microsoft/TypeScript/pull/6885 를 참조하세요.

네 감사합니다

private 생성자는 또한 클래스를 클래스에서 인스턴스화할 수 없도록 만들지 않습니까? 기말고사 정답이 아닙니다.

Java 및/또는 C#은 final 클래스를 사용하여 특수화되지 않을 것임을 알고 런타임에 클래스를 최적화합니다. 이것이 내가 주장하는 최종 지원의 주요 가치입니다. TypeScript에는 final이 없는 것보다 더 나은 코드 실행을 위해 제공할 수 있는 것이 없습니다.
사용자에게 클래스의 올바른 사용을 알리기 위해 주석을 사용하고 최종 클래스를 노출하지 않고 대신 인터페이스를 노출하는 것을 고려하십시오.

나는 그것에 동의하지 않고 대신 duanyao에 동의합니다. Private은 그 문제를 해결하지 못합니다. 왜냐하면 최종 클래스도 생성자를 사용하여 인스턴스화할 수 있기를 원하기 때문입니다. 또한 사용자에게 노출하지 않으면 추가 팩토리를 작성해야 합니다. 나에게 최종 지원의 주요 가치는 사용자가 실수하지 않도록 방지하는 것입니다.
다음과 같이 주장합니다. 함수 서명에서 유형을 사용할 때 TypeScript는 내 코드를 더 빠르게 실행하기 위해 무엇을 제공합니까? 사용자의 실수를 방지하기 위한 것이기도 하지 않습니까? 사용자가 매개변수로 전달해야 하는 값의 유형을 설명하는 주석을 작성할 수 있습니다. 최종 키워드와 같은 확장이 그냥 밀려난다는 것은 유감입니다. 제 생각에는 이것이 typescript의 원래 의도와 충돌하기 때문입니다. 최대한 많은 실수를 피하기 위해 최대한 많은 검사를 수행하는 컴파일 수준을 추가하여 JavaScript를 더 안전하게 만드십시오. 최대한 미리. 아니면 TypeScript의 의도를 잘못 이해한 걸까요?

메서드에는 final 수정자가 있어야 합니다.

class Foo {
  final fooIt():void{

  }
}

class Bar {
  fooIt():void {

  }
}
// => Method fooIt of Bar cannot override fooIt of Foo, because it is final.

예를 들어 나는 fooIt이 재정의되는 것을 긴급히 피하고 싶은 다음과 같은 패턴을 자주 사용합니다.

import Whatever ...

abstract class Foo {
  private ImportantVariable:boolean;

  protected abstract fooIt_inner:Whatever();

  public final fooIt():Whatever() {
    //do somestate change to aprivate member here, which is very crucial for the functionality of every Foo:
    ImportantVariable = true;
    //call the abstract inner functionality:
    return this.fooIt_inner();    
  }
}

비용 대 효용에 대한 논쟁은 상당히 주관적입니다. 주요 관심사는 모든 새로운 기능, 구성 또는 키워드가 언어 및 컴파일러/도구 구현에 복잡성을 추가한다는 것입니다. 언어 디자인 회의에서 우리가 하려고 하는 것은 장단점을 이해하고, 부가 가치가 도입된 복잡성을 더 중시할 때만 새로운 기능을 추가하는 것입니다.

커뮤니티 구성원이 계속 피드백을 추가할 수 있도록 문제가 잠겨 있지 않습니다. 충분한 피드백과 설득력 있는 사용 사례가 있으면 문제를 다시 열 수 있습니다.

실제로 final은 매우 간단한 개념이며 언어에 복잡성을 추가하지 않으며 추가해야 합니다. 적어도 방법에 대해서는. 많은 사람들이 큰 프로젝트에서 작업할 때 다른 사람이 재정의해서는 안 되는 메서드를 재정의하도록 허용하지 않는 것이 가치가 있습니다.

TypeScript에는 final이 없는 것보다 더 나은 코드 실행을 위해 제공할 수 있는 것이 없습니다.

와, 찡해! 정적 유형은 코드 실행을 향상시키지 않지만 안전은 좋은 것입니다.

최종(봉인된)는 클래스 사용자 정의를 좀 더 안전하게 만들기 위해 보고 싶은 기능으로 재정의와 함께 바로 위에 있습니다. 나는 성능에 신경 쓰지 않는다.

정적 유형은 코드 실행을 향상시키지 않지만 안전은 좋은 것입니다.

정확히. private 다른 사람이 메서드를 호출하지 못하도록 하는 것처럼 final 는 다른 사람이 메서드를 재정의하지 못하도록 제한합니다.

둘 다 외부 세계와의 클래스 OO 인터페이스의 일부입니다.

@pauldraper 및 @mindarelus에 완전히 동의합니다. 이것을 구현하십시오. 이것은 많은 의미가 있을 것입니다. 나는 현재 그것을 정말로 그리워합니다.

나는 final이 성능에만 도움이 된다고 생각하지 않고 디자인에도 도움이 된다고 생각하지만 TypeScript에서는 전혀 의미가 없다고 생각합니다. Object.freeze 및 Object.seal 의 가변성 효과를 추적하여 이것이 더 잘 해결된다고 생각합니다.

@aluanhaddad 더 자세히 설명해 주시겠습니까? 이것이 "TypeScript에서 전혀 의미가 없다"고 생각하는 이유는 무엇입니까?
개체를 고정하거나 봉인한다는 것은 개체에 새 속성을 추가하는 것을 허용하지 않지만 파생된 개체에 속성을 추가하는 것을 방지하지 않는다는 것을 의미하므로 기본 클래스를 봉인하더라도 해당 기본 클래스를 확장하는 자식 클래스의 메서드를 계속 재정의할 수 있습니다. . 또한 런타임에 기본 클래스에 속성을 추가할 수 없습니다.

Java의 클래스 또는 클래스 메서드에 final 를 사용한다는 아이디어는 제 생각에는 스레드 안전을 위해 개체의 변경 가능성을 최소화하는 것과 더 관련이 있습니다. (항목 15. Joshua Bloch, 효과적인 자바)

JS의 모든 것이 변경 가능하기 때문에 이러한 원칙이 자바스크립트로 넘어가는지 모르겠습니다(제가 틀렸다면 수정해 주세요). 하지만 Typescript는 Javascript가 아닙니다. 네?

나는 이것이 구현되는 것을 정말로 보고 싶습니다. 더 강력한 코드를 만드는 데 도움이 될 것이라고 생각합니다. 이제... 그것이 JS로 어떻게 번역되는지, 솔직히 아마도 그럴 필요가 없을 것입니다. 나머지 컴파일 시간 검사가 있는 펜스의 typescript 쪽에 있을 수 있습니다.

물론 그것 없이는 살 수 있지만 그것이 typescript의 일부입니다. 맞습니까? 우리가 간과한 실수를 다시 확인합니까?

나에게 final 는 private 또는 타이핑, 즉 코드 계약과 같은 typescript의 역할을 합니다. 코드 계약이 깨지지 않도록 하는 데 사용할 수 있습니다. 너무 좋아요.

@hk0i 또한 여기에 반향된 것과 유사한 방식으로 항목 17(2판)에 언급되어 있습니다.

그러나 일반 콘크리트 클래스는 어떻습니까? 전통적으로, 그것들은 하위 분류를 위해 최종적이거나 설계 및 문서화되지 않았지만 이러한 상황은 위험합니다. 이러한 클래스가 변경될 때마다 해당 클래스를 확장하는 클라이언트 클래스가 중단될 가능성이 있습니다. 이것은 단지 이론적인 문제가 아닙니다. 상속을 위해 설계 및 문서화되지 않은 비최종 구체 클래스의 내부를 수정한 후 서브클래싱 관련 버그 보고서를 받는 것은 드문 일이 아닙니다.

이 문제에 대한 최선의 해결책은 안전하게 서브클래싱되도록 설계 및 문서화되지 않은 클래스에서 서브클래싱을 금지하는 것입니다. 하위 분류를 금지하는 두 가지 방법이 있습니다. 둘 중 더 쉬운 것은 클래스를 final로 선언하는 것입니다. 대안은 모든 생성자를 private 또는 package-private로 만들고 생성자 대신 공용 정적 팩토리를 추가하는 것입니다.

나는 추상 키워드가 이미 존재한다는 점을 감안할 때 언어의 인지적 복잡성을 증가시키지 않는다고 주장합니다. 그러나 나는 그것의 구현/성능 영향에 대해 말할 수 없으며 그 각도에서 언어를 보호하는 것을 절대적으로 존중합니다. 이러한 우려를 분리하는 것이 이 기능을 구현할지 여부를 결정하는 데 도움이 될 것이라고 생각합니다.

나는 final 가 수업을 봉인하는 훌륭한 추가가 될 것이라고 믿습니다. 한 가지 사용 사례는 클래스에 많은 공용 메서드가 있지만 인터페이스를 통해 그 중 일부만 노출할 수 있다는 것입니다. 실제 소비자는 인터페이스를 사용하여 액세스를 제한하는 동안 이러한 모든 공용 메서드가 있으므로 구현을 빠르게 단위 테스트할 수 있습니다. 구현을 봉인할 수 있으면 누구도 구현을 확장하거나 공용 메서드를 변경하지 않도록 할 수 있습니다.

당신은 또한 아무도 당신의 클래스를 상속받지 않도록 할 수 있습니다. TypeScript는 이러한 규칙을 적용해야 하며 주석에 대한 제안은 이 사용 사례를 해결하기 위한 게으른 접근 방식인 것 같습니다. 내가 읽은 다른 답변은 특정 상황에만 적합하지만 위에서 설명한 상황에는 적합하지 않은 private 사용에 관한 것입니다.

이 스레드의 많은 사람들과 마찬가지로 저는 수업을 봉인할 수 있도록 투표할 것입니다.

@mhegazy Private 생성자와 봉인/최종 클래스는 의미 체계가 매우 다릅니다. 물론 개인 생성자를 정의하여 확장을 방지할 수 있지만 클래스 외부에서 생성자를 호출할 수도 없습니다. 즉, 인스턴스를 생성할 수 있도록 정적 함수를 정의해야 합니다.

개인적으로 나는 봉인/최종으로 표시된 클래스와 메서드가 확장되거나 재정의될 수 없도록 봉인/최종 컴파일러 검사를 권장합니다.

내 문제의 맥락에서 객체를 인스턴스화할 수 있도록 공용 생성자를 가질 수 있기를 원하지만 클래스의 확장을 방지하고 sealing/final의 추가만 허용합니다.

작업이 있습니다 - 코드를 작성하십시오

• 변경할 수 없는 개체를 작동
• 상속이 자유롭다
• 반사 방법 무료

그리고 여기에 final 키워드가 필요합니다, IMHO.

final 는 보호해야 하는 메서드와 재정의해서는 안 되는 메서드를 자신과 사용자에게 상기시키는 좋은 방법이라고 생각합니다. 참고로 저는 또한 독자가 부분적으로 알 수 있도록 하지만 메서드 이름을 입력하면 트랜스파일러가 불평할 수 있도록 재정의하고 있음을 명시적으로 언급하는 것을 지지합니다.

@zigszigsdk 메서드는 재정의되지 않으므로 어떻게 작동합니까?

final :
this 컨텍스트에서 final로 선언된 super의 메소드를 숨기면 트랜스파일러가 불평한다는 점을 제외하면 지금 작동하는 것과 같은 방식입니다.

override :
지금과 같은 방식으로 작동하지만, 트랜스파일러가 override 메소드를 선언하고 수퍼에 해당 이름의 메소드가 없거나 메소드가 있지만 final 선언된 경우 트랜스파일러가 불평한다는 점을 제외하고는
this 컨텍스트에서 super의 메소드를 숨기고 재정의를 명시하지 않으면 경고가 될 수도 있습니다.

Java 및/또는 C#은 최종 클래스를 사용하여 특수화되지 않을 것임을 알고 런타임에 클래스를 최적화합니다. 이것이 내가 주장하는 최종 지원의 주요 가치입니다.

@mhegazy 별로! 또 다른 중요한 기능은 재정의될 것으로 예상되는 클래스 부분을 명시하는 것입니다.

예를 들어 "Effective Java"의 항목 17을 참조하십시오. "상속을 위한 설계 및 문서화 또는 금지":

상속을 위해 설계 및 문서화되지 않은 비최종 구체 클래스의 내부를 수정한 후 서브클래싱 관련 버그 보고서를 받는 것은 드문 일이 아닙니다. 이 문제에 대한 최선의 해결책은 안전하게 서브클래싱되도록 설계 및 문서화되지 않은 클래스에서 서브클래싱을 금지하는 것입니다. 하위 분류를 금지하는 두 가지 방법이 있습니다. 둘 중 더 쉬운 것은 클래스를 final 로

제 생각에는 최종 방법도 마찬가지입니다. 이 클래스가 공개 방법을 재정 지원하도록 설계되어 매우 드물다. 재정의되지 않은 동작과 재정의하는 동작의 조합으로 인해 발생할 수 있는 모든 가능한 상태 조합을 생각해야 하므로 매우 복잡한 디자인과 엄청난 양의 테스트가 필요합니다. 따라서 프로그래머는 하나 또는 두 개를 제외한 모든 공용 메서드를 final로 선언할 수 있으므로 이러한 조합의 수가 크게 줄어듭니다. 그리고 그렇지 않은 경우가 더 많습니다. 하나 또는 두 개의 재정의 가능한 메서드가 정확히 필요한 것입니다.

final 클래스와 메소드가 매우 중요하다고 생각합니다. 시행하시길 바랍니다.

또 다른 매력적인 사용자 사례 @mhegazy . 오늘 나는 Template Method Pattern 을 배웠고, wikipedia 의 final 가 필요하다는 것을 발견했습니다. 하지만 내 멋진 TypeScript에서는 이것을 할 수 없습니다. 유감입니다!

템플릿 패턴을 사용하면 하위 클래스에서 알고리즘의 구조를 변경하지 않고도 알고리즘의 특정 단계를 재정의할 수 있습니다.

나에게 그것은 상속이 아닌 경우에 구성을 시행하는 것만큼 간단합니다. final 없이는 할 수 없습니다.

final 가 typescript에 오는 것을 보고 싶은 만큼 Microsoft가 우리에게 보내려고 하는 기본 메시지는 우리가 final 원한다면 다음과 같은 언어를 사용해야 한다는 것입니다. 지원합니다.

이 문제가 다시 열리고 구현되는 것을 보고 싶습니다.

내부적으로 사용하거나 공개적으로 공유할 라이브러리를 구축할 때(예: npm에서) 라이브러리를 사용하는 사람들이 코드를 탐색하고 주석이나 문서를 검색하여 클래스가 할 수 있는지/할 수 있는지 확인하는 것을 원하지 않습니다. 덮어쓰지 않습니다. 덮어쓰면 오류가 발생합니다.

내 코드에는 확장되는 클래스가 있으며 일종의 이벤트가 발생하면 메서드가 트리거됩니다. 하위 클래스가 메서드를 정의하면 그렇지 않으면 기본 클래스로 폴백됩니다. 그러나 클래스에 "대체" 메서드가 아닌 다른 메서드도 있습니다. DOM에 항목을 추가하는 것과 같은 도우미 메서드에 가깝습니다. 이 경우 이러한 메서드를 덮어쓰는 것을 원하지 않습니다.

이 주제에 대한 나의 5센트는 이것이 다시 열리고 구현되어야 한다는 것입니다.

나는 그것을 사용하여 라이브러리의 클라이언트가 이미 존재하는 다른 클래스에서 확장되지 않고 고유한 구체적인 클래스를 만들도록 강제할 것입니다. @lucasyvas가 말했듯이 구성을 선호하십시오. 또는 예를 들어 각도에서 종속성 주입을 제공하기 위해 새로운 구체적인 클래스 구현을 시행하십시오.

나는 또한 수업과 방법을 모두 지원하여 재개방에 투표합니다.

나는 우리가 최종 키워드의 패턴이 typescript의 맥락에서 어떻게 작동할지 확신이 서지 않아야 한다고 말하지 않습니다.

최종 키워드는 사용자/프로그래머가 해당 클래스/메서드에서 재정의/상속하는 것을 중지하지 않습니까?

Final을 보는 나의 방식은 더 이상 변경할 수 없음을 의미하는 데이터를 "고정"한다는 것입니다. 내 말은 이것이 "버그"를 수정하거나 일부 동작을 변경하려는 사람들에게 정말 번거로울 수 있지만 사용하는 것이 좋습니다.

@niokasgami Freeze는 [data](https://developer.mozilla.org/fr/docs/Web/JavaScript/Reference/Objets_globaux/Object/freeze)와 관련이 있습니다.
이미 ES6의 일부로 사용 가능합니다. Final은 클래스와 메서드에 적용됩니다(변수는 읽기 전용일 수 있으므로 슈퍼 변수를 재정의할 수 없으므로 "최종"으로 작동합니다).

"Final" 키워드는 JAVA 에서 사용되며, C# 에서는 sealing이 되어 있습니다.

typescript는 C#에서 강하게 영감을 받았기 때문에 "봉인된" 것이 선택될 가능성이 더 높아야 합니다. 이제 기본적으로 런타임에 개체를 봉인 하는

@Xample Java의 로컬 변수에 final을 사용할 수도 있다고 생각합니다. 안드로이드 앱을 작성할 때 이 작업을 수행해야 했던 기억이 납니다. 이벤트와 함께 해야 한다고 생각하지만 100% 확신할 수는 없습니다.

function(){
    let final myVariable = 'Awesome!'
    document.addEventListener('scroll', e => {
        console.log(myVariable)
        myVariable = 'Not Awesome' // Throws an error
    })
}

@TheColorRed 음, Java의 최종 지역 변수는 상수를 의미하지 않습니까?

@EternalPhane 제 생각에는 항상 const 같은 전역 범위에서 사용했습니다... 함수나 메서드 내에서 사용할 생각은 한 번도 하지 않았습니다... 그러면 이전 주석이 무효인 것 같습니다...

@Xample 예, C#에서 Sealed에 대한 귀하의 요점이 동일하게 작동하지 않습니다. 솔직히 제 생각에는 키워드 seal과 final 모두 혼동될 수 있기 때문에 범주에 들어갈 수 없었습니다. Java에서 상수로 사용되기 때문에 적용하는 방법 :/

Java에서는 모든 변수, 메서드 또는 클래스를 final 할 수 있습니다. 변수의 경우 참조를 재할당할 수 없음을 의미합니다(참조가 아닌 유형의 경우 값도 변경할 수 없음을 의미합니다). 클래스의 경우 확장이 없음을 의미합니다( extends ... 키워드). 메서드의 경우 하위 클래스에서 재정의가 없음을 의미합니다.

Java에서 final 를 사용하는 주요 이유:

• 변수의 불변성 감소: 스레드 안전을 위해
• 클래스를 상속할 수 없도록 마무리: 하위 클래스가 실수로 슈퍼 메서드를 호출하기 시작할 때 상속이 본질적으로 복잡하기 때문에 상속보다 합성을 강제합니다.
• 간단한 프로그래밍 오류 방지: 값을 변경할 의도가 없다면 더 이상 가능하지 않습니다.
• 대부분의 사람들이 상수를 상상할 때 생각하는 것에 사용: public static final String KEY = "someStringKeyPathHere" 에서와 같이 어디에서나 볼 수 있는 재사용 가능한 값은 실수를 줄이는 데 유용하지만 동일한 값에 대해 여러 문자열 개체를 다시 만들지 않는다는 추가 컴파일 시간 이점이 있습니다.

몇 가지 사용 사례를 생략했을 수 있지만 매우 일반적으로 유지하고 몇 가지 예를 제공하려고 했습니다.

@TheColorRed Android는 콜백(익명 클래스) 외부에서 변수를 선언한 다음 내부에서 참조할 때 필요합니다. 나는 이것이 스레드 안전 문제와 다시 일치한다고 생각합니다. 나는 그들이 당신이 다른 스레드에서 변수를 재할당하는 것을 막으려 한다고 생각합니다.

유용함에도 불구하고 이 기능이 곧 제공될 것이라고 생각하지 않습니다. 다른 솔루션을 살펴보거나 내 경우와 같이 typescript를 모두 삭제하고 JS의 엉성함을 처리하는 것이 좋습니다. Javascript에는 이러한 유형의 힌트가 없거나 궁극적으로 코드가 JS로 변환되지 않아 많은 "이점"이 있습니다. 브라우저 호환성을 원하면 ES6을 작성하고 Babel을 사용하여 변환할 수 있습니다.

이러한 이점 중 일부를 위해 손목을 때릴 수는 있지만 js로 변환된 후에는 java-esque final 의 실제 이점을 전혀 얻지 못한다고 현실적으로 생각합니다.

@hk0i 나는 당신의 요점을 이해할 수 있다고 생각하지만 전반적으로 당신의 의견에 대해 동의하고 동시에 약간 동의하지 않습니다.

typescript에 있는 대부분의 코드는 프로그래머가 잘 할 수 있도록 디버깅/추적 목적으로 말하고 싶습니다. "clean" 코드를 수행하는 것 같습니다.

대부분의 typescript 기능은 JS에 존재하지 않기 때문에 JS로 변환할 때 대부분의 경우 변환되지 않습니다.

코드를 런타임/작성할 때 코드의 오류를 확인하고 JS보다 더 쉽게 추적하는 데 도움이 되지만(HECK JS는 버그를 추적하기 어려울 수 있음 ㅋㅋ)

그래서 final 키워드의 사용은 API 사용자가 알 수 있는 차단기로 보일 수 있다고 생각합니다.

Typescript가 좋은 언어라는 것은 사람들이 클래스 생성자를 호출하는 것을 막지만 여전히 액세스할 수 있는 "진정한" 정적 클래스 키워드와 같은 몇 가지 중요한 기능이 부족하다는 사실을 알게 되어 안타깝습니다.

@hk0i 저도 동의하지 않습니다. typescript의 목적은 코드를 구조화하여 이를 위한 도구를 제공하는 것입니다. 우리는 Java에서 final을 사용할 필요가 없습니다. 일반적으로 클래스나 메서드를 확장하면 부작용이 발생할 수 있다는 것을 알 때 사용합니다(또는 다른 안전상의 이유로).

런타임 가변성 검사(Object.seal 또는 Object.freeze 사용)를 추가하는 현재 ES6 솔루션에 의존하면 코드를 입력할 때 직접 오류가 발생하는 이점을 잃게 됩니다( 이 데코레이터를 사용하여 쉽게 수행할 수 있음에도 불구하고).

@TheColorRed 예… 그리고 typescript에서 우리는 지역 변수와 클래스 변수를 구별합니다.

• readonly 클래스 변수
• const : 다른 변수의 경우

그들 중 어느 것도 방법이나 클래스에 대해 정확하지 않을 것입니다. 메서드를 재정의한다고 해서 메서드를 재정의한다는 의미는 아닙니다(C++의 가상 메서드에서 생각). 메서드가 상위 메서드보다 먼저 호출되도록 정의하기만 하면 됩니다( super 사용하여 호출할 수 있음).

@niokasgami 아마도 명명은 실제로 문제가 되지 않을 것입니다. 우리는 Object.seal이 객체에 적용된다는 것을 여전히 이해할 것입니다. 클래스와 메서드를 구조 자체에 봉인하는 동안.

TL;DR:

• preventExtensions는 클래스 확장을 방지하는 좋은 명시적 이름입니다.
• preventOverrides는 클래스 재정의를 방지하기 위한 좋은 후보 이름입니다.
  그러나 seal 는 C#에서 널리 사용되며 더 짧고 예상되는 동작이 동일합니다.

그런데 Object.preventExtensions() 도 있다는 언급을 잊었습니다.
차이점은 여기에서 볼 수 있습니다.

독서

• 항상 가능... 누가 쓰기 전용 변수를 원합니까?

업데이트 및 삭제

• 삭제 변수 재정의 방지: 클래스 멤버의 경우 읽기 전용, const(다른 멤버의 경우)
• 메소드 재정의 방지: (클래스 메소드 내에서) this.aMethod = ()=>{} 하는 것을 방해하는 것은 없습니다. 이러한 해킹을 방지하려면 메소드도 readonly 여야 합니까? delete this.aMethod 대해 동일

생성

• 객체에만 적용되거나 여기서 구조체에 대해 이야기할 때: class 클래스가 객체의 멤버를 정의한 것처럼 typescript는 이미 암시적으로 새 속성을 즉석에서 생성하는 것을 방지합니다… 예를 들어 this.unKnownProperty = "something" ts 예상대로 컴파일 시간 오류 TS2339 가 발생합니다.

연장

• 클래스에만 적용되며 아직 객체 자체에 대해 아무 것도 하지 않습니다… (런타임에 생성 하는 것과는 달리). 여기서 final 또는 seal 가 관련됩니다. 문제는 ES6의 동결, 봉인 및 preventExtensions 와 일관성을 유지하는 방법입니다. (필요한 경우).
  클래스를 확장한다는 것은 이 클래스에서 다른 클래스를 생성하는 것을 방지한다는 의미입니다. 그러면 읽을 수 있지만 삭제할 수는 없습니다(어쨌든 클래스를 삭제하는 사람). 질문은 "업데이트" 열이 아닙니다. final 클래스를 업데이트할 수 있습니까? 업데이트 가능한 클래스란 무엇입니까? 제 추측으로는 그렇습니다... 하지만 업데이트는 이 클래스를 구현하는 것입니다(클래스의 인터페이스 이해)? 다른 클래스를 구현하는 것은 항상 가능해야 하지만… 초기 클래스를 업데이트하는 것과는 관련이 없습니다. 글쎄... 아마도 그들은 단순히 C#을 작성하는 동일한 질문에 와서 seal 가 좋은 키워드라고 결정했을 것입니다.

우선

• 확장 클래스에서 현재 메서드를 재정의하는 것을 방지합니다. 다시 말하지만, 정의(클래스 내의 메서드)에 대해 이야기할 때 아직 아무 것도 덮어쓰지 않습니다. 따라서 생성 방지, 읽기 허용, 업데이트 허용(메소드에도 적용 가능한 경우 readonly를 사용하여 메서드 업데이트 또는 삭제를 방지할 수 있음). 최고의 네이밍? preventOverrides ? 또는 C#에서 사용되는 것처럼 다시 seal

보너스: 메소드를 봉인하는 것은 일반적으로 사람들이 필수 수퍼 코드를 무시하는 것을 방지하기 위한 것이므로 사람들이 수퍼 메소드 (생성자와 동일한 동작이지만 모든 메소드에 대해)

오해하지 마세요, 저는 이에 반대하지 않습니다. 나는 그것에 대해 매우 좋아합니다. 나는 단지 그것이 기능이 되어서는 안 된다는 마이크로소프트의 역설적 사고방식을 이해하려고 노력하고 있습니다. 본질적으로 이것은 JavaScript 기능이 아니기 때문에 TypeScript 기능이 될 수 없다는 것입니다.

... 내가 올바르게 이해하고 있다면.

@hk0i Generics, readonly, 기타 많은 기능들은 JavaScript 기능이 아니지만 여전히 TypeScript에 추가되어 있기 때문에 그 이유는 아니라고 생각합니다...

TypeScript는 간단하지 않은 방식으로 코드를 생성해야 하는 기능만 피합니다. 제네릭, 읽기 전용 등은 생성된 출력을 생성하기 위해 간단히 지울 수 있는 순전히 컴파일 타임 개념이므로 공정한 게임입니다.

final 는 컴파일 시간에도 "지울 수" 있는데 왜 "공정한 게임"이 되지 않습니까?

🤷‍♂️

@ColorRed 나는 이것이 통합해야 할 다른 우선 순위가 있다고 생각합니다.
또는 이 새 키워드가 컴파일/코딩 시간에 얼마나 예측 가능한지 확신할 수 없습니다. 생각해보면 최종 키워드의 디자인은 매우 모호할 수 있습니다. final은 많은 목적을 위해 많이 사용될 수 있습니다. Jsdoc 문서에서 볼 수 있듯이 jsdoc 인터프리터에 이 변수가 고정되어 읽기 전용임을 알려주는 "@final" 태그를 사용할 수 있습니다.

여기에 디자인 충돌이 있습니다. 읽기 전용은 변수를 "고정"하고 읽기 전용으로 만들고 최종적으로 최종적으로 읽기 전용으로 만드는 것을 기억하면 변수 및 게터에 적용할 수 있습니다.

이것은 변수에 최종 태그를 지정해야 하는지 읽기 전용으로 태그를 지정해야 하는지 확실하지 않은 프로그래머에게 혼란을 일으킬 수 있습니다.

이 키워드를 클래스 및 메서드 선언 전용으로 예약하지 않는 한, behavior 또는 final이 읽기 전용과 충돌할 것이라고 생각합니다.

봉인(object.seal과 충돌할 수 있음) 또는 최종(이 목적 설계가 읽기 전용 키워드와 충돌함) 대신에 이름을 지정하고 설계하는 보다 "직접적인" 방법을 사용할 수 있다고 생각합니다.

이것은 C# 행동과 유사하지만 동시에 다른 행동에 대한 "아이디어"일 뿐이라는 점에 유의하십시오. C#이 일반적으로 재정의할 수 없는 방법에서 영감을 얻었고 이 방법이 가상이라고 말해야 합니다.

` 네임스페이스 예 {

export class myClass {

    constructor(){}

    // Make the func non ovveridable by inheritance. 
    public unoveridable myMethod(){

    }

    public myMethodB(){

    }
}

export class MyClassB extends myClass {

    // Nope not working will throw an error of an nonOverridable error
    myMethod(){
        super.myMethod();
    }

    // Nope will not work since unoverridable.
    myMethod(){

    }

    // Design could be implemented differently since this could complicate  ¸
    // the pattern of typescript
    public forceoverride myMethod(){
      // destroy previous pattern and ignore the parent method thus a true ovveride
    }

    // Yup will work since it's still "virtual".
    myMethodB(){
        super.myMethodB();
    }
}
// Can extend an existing Parent class
// Declaring an unextendable class make all is component / func nonOverridable by 
// inheritance. (A class component can still be overwritten by prototype usage.)
export unextendable class MyFinalClass extends Parent {

    constructor()

    // nonoverridable by default.
    public MyMethod(){

    }
}
// nope throw error that MyFinalClass is locked and cannot be extended
export class MyChildClass extends MyFinalClass{}

}`

편집 : Variable을 포함하지 않았고 readonly가 이미 존재하기 때문에 가져옵니다.

@mhegazy 이 문제를 다시 final ), C#( sealed , readonly ), PHP와 같이 final 키워드를 추가하는 쪽에 압도적으로 많은 것 같습니다 final ( final ), Scala ( final , sealed ) 및 C++ ( final , virtual )가 있습니다. 이 기능이 없는 정적으로 유형이 지정된 OOP 언어는 생각할 수 없으며 TS가 필요하지 않은 이유에 대한 설득력 있는 주장도 듣지 못했습니다.

@bcherny @mhegazy 위의 내용에 전적으로 동의합니다. final 가 TypeScript에서 볼 수 있는 대부분의 구문 설탕과 같이 또 다른 컴파일 시간 제약이 될 수 없는 이유를 알 수 없습니다. 정적 타이핑, 제네릭, 액세스 수정자, 유형 별칭 , 인터페이스 ... 모든 설탕! TypeScript 팀은 아마도 다른 방향으로 언어를 사용하는 데 집중하고 싶어 할 것입니다. 하지만 진지하게 이것은 OOP 101입니다... 이것은 TypeScript가 아직 아주 어렸을 때 꽤 오래전에 했어야 했습니다!

@mhegazy 이 문제에 대해 귀하가 작성한 초기 댓글을 다시 참조할 수 있습니까?

private 생성자가 있는 클래스는 확장할 수 없습니다. 대신 이것을 사용하는 것을 고려하십시오.

이 댓글은 21번의 반대 투표를 받았습니다.
분명히 이것은 커뮤니티가 솔루션으로 원하는 것이

와우, 이것에 대해 많은 피드백을 받았습니다. 구현에 관심이 없는 이유를 이해할 수 없습니다.

여기에서 정말 비생산적인 불평이 많이 일어나고 있습니다. 불만을 표출하지 마십시오. 여기에서 우리가 결정을 내릴 수 있고 커뮤니티에서 피드백을 제공할 수 있습니다. 하지만 그냥 아무렇게나 이를 갈기만 하면 다른 사람의 마음이 바뀌지 않습니다. 구체적이고 실행 가능해야 합니다. 지금 이 기능을 사용하세요 라고 말하기 위해 나타나는 사람들에 의해 우리는 확신하지 못할 것입니다.

이 문제는 final/sealed 클래스에 관한 것 입니다. 완전히 다른 개념인 최종/봉인된 방법에 대한 주제에서 벗어난 토론이 있었습니다.

지난 번 검토할 때 몇 가지 점을 고려했습니다.

• 클래스는 TYPESCRIPT 기능이 아니라 JAVASCRIPT 기능 입니다. final 없으면 수업이 완전히 무용지물이라고 생각되면 TC39 위원회와 상의하거나 es-discuss에 제출해야 합니다. final 가 필수 기능이라고 TC39에게 확신을 줄 수 있는 사람이 없다면 TypeScript에 추가하는 것을 고려할 수 있습니다.
• 무언가에서 new 를 호출하는 것이 합법적인 경우 해당 항목에서 상속하는 것과 일대일 런타임 대응이 있습니다. new 'd가 될 수 있지만 super 'd가 아닌 무언가의 개념은 JavaScript에 존재하지 않습니다.
• TypeScript가 OOP 키워드 수프가 되는 것을 피하기 위해 최선을 다하고 있습니다. JavaScript에는 상속보다 더 나은 구성 메커니즘이 많이 있으며 C# 및 Java에 있는 모든 단일 키워드를 가질 필요 는 없습니다.
• "should-be-final" 클래스에서 상속을 감지하기 위해 런타임 검사를 간단하게 작성할 수 있습니다. 모든 소비자가 TypeScript를 사용하는 것은 아니기 때문에 누군가 실수로 클래스에서 상속하는 것에 대해 "걱정"하는 경우 실제로 수행해야 합니다. .
• 특정 클래스가 상속되지 않는 스타일 규칙을 적용하는 린트 규칙을 작성할 수 있습니다.
• 누군가가 "실수로" 봉인되어야 하는 클래스에서 상속받는 시나리오는 일종의 이상한 시나리오입니다. 나는 또한 주어진 클래스에서 상속받는 것이 "가능"한지 여부에 대한 누군가의 개별적인 평가가 아마도 다소 의심스럽다고 주장하고 싶습니다.
• 기본적으로 클래스를 봉인하는 세 가지 이유는 보안, 성능 및 의도입니다. 그 중 두 가지는 TypeScript에서 의미가 없으므로 다른 런타임에서 수행하는 작업의 1/3만 수행하는 복잡성 대 이득을 고려해야 합니다.

이 모든 것에 동의하지 않으셔도 되지만 final 의 부족이 JavaScript 클래스를 효과적으로 사용하는 능력에 어떻게 해를 끼치는지에 대한 실행 가능하고 구체적인 피드백을 가져오십시오.

TS가 필요하지 않은 이유에 대한 설득력 있는 주장을 듣지 못했습니다.

이것이 작동하는 방식이 아님을 상기하십시오. 모든 기능은 -100 에서 시작 합니다. 해당 게시물에서

이러한 질문 중 일부에서 질문은 특정 기능을 "제거"하거나 "제외"한 이유를 묻습니다. 이 문구는 기존 언어(C++ 및 Java가 여기에서 인기 있는 선택임)로 시작한 다음 원하는 지점에 도달할 때까지 기능을 제거하기 시작했음을 의미합니다. 그리고 일부 사람들에게는 믿기 어려울 수 있지만 언어는 그렇게 설계되지 않았습니다.

우리는 유한한 복잡성 예산을 가지고 있습니다. 우리가 하는 모든 일은 다음에 하는 모든 일을 0.1% 느리게 만듭니다. 기능을 요청하면 다른 모든 기능이 조금 더 어려워지고, 조금 느려지고, 가능성이 조금 낮아질 것을 요청하는 것입니다. Java가 있기 때문에 또는 있기 때문에 또는 되고 명령줄 스위치를 추가할 수 있기 때문에 여기에는 아무 것도 들어가지 않습니다 . 기능은 자신과 미래에 대한 전체 부담에 대한 비용을 지불해야 합니다.

@RyanCavanaugh 결정에 동의하는지 확신할 수 없지만, 정말 사려 깊고 상세한 답변과 시간을 내어 작성해 주셔서 감사합니다. 나는 당신이 언어를 간결하게 유지하기를 원한다는 것을 알았습니다. 다른 인기 있는 언어가 가지고 있는 기능이 정말로 가치가 있는지, 아니면 그냥 일반적인지 생각해 보는 것이 좋습니다.

@RyanCavanaugh

이 포럼의 요점은 .. "JavaScript 클래스를 효과적으로 사용하십시오."라고 생각하지 않습니다.

죄송합니다. 저는 저항할 수 없으며 "여기서 계속되고 있는 비생산적인 불평"에 추가합니다. 마지막 키워드는 설명된 모든 이유에 대해, 상세하게, 그리고 다른 사람들의 주장과 함께 유용합니다.

TypeScript가 OOP 키워드 수프가 되는 것을 피하기 위해 최선을 다하고 있습니다. JavaScript에는 상속보다 더 나은 구성 메커니즘이 많이 있습니다...

final 를 사용하여 상속에 대한 구성을 적용할 때와 같이 (여기에 typescript 언어 이름이 아닌 삽입) 😈
(미안, 저항할 수 없었어)

그러나 더 중요한 것은 TS가 일부 추가 유형 검사를 추가한다는 점을 제외하고는 "오늘날의 JavaScript 지금" 또는 그 효과(예: Babel)를 도입하기 위한 호환성 계층이 대부분인 것 같습니다.

이것을 구현하기 위한 반대 논거의 요지는 다른 언어의 기능을 원하면 대신 다른 언어를 사용하라는 것입니다. JavaScript를 원하시면 JavaScript를 사용하십시오. TypeScript를 원하면 그것을 사용하십시오.

Kotlin이 JS로 컴파일할 수 있고 여기 사람들이 즐길 수 있는 많은 기능이 있다는 것을 알고 있으므로 살펴보는 데 유용할 수 있습니다. 나는 그것이 의존성으로 일부 JS 라이브러리를 추가한다고 생각합니다 (직접 시도하지는 않았습니다).

TypeScript가 마음에 들지 않으면 사용하지 마십시오.

@RyanCavanaugh

위에 올려주신 포인트에..

클래스는 TYPESCRIPT 기능이 아니라 JAVASCRIPT 기능 입니다. final 없으면 수업이 완전히 무용지물이라고 생각되면 TC39 위원회와 상의하거나 es-discuss에 제출해야 합니다. final 가 필수 기능이라고 TC39에게 확신을 줄 수 있는 사람이 없다면 TypeScript에 추가하는 것을 고려할 수 있습니다.

저는 0.7부터 TypeScript를 따라왔고 그 당시 IIRC는 ES3-ES5를 대상으로 했습니다. 그 당시 클래스는 확실히 TypeScript 기능이었습니다. 데코레이터에도 동일한 주장이 적용됩니다. ES용 카드에 있지만 이미 TypeScript에 실험적 기능으로 포함되어 있습니다.

커뮤니티로서 우리는 TypeScript 컴파일러가 final JavaScript 클래스를 어떻게든 방출해야 한다고 주장하지 않습니다. 액세스 수정자에 대한 컴파일 시간 확인과 동일한 방식으로 컴파일 시간 확인으로 충분합니다. 결국, 그것들은 JavaScript 기능도 아니지만 TypeScript는 여전히 그것들을 가능하게 합니다.

final 가 ES 기능이 된 경우 ES*를 대상으로 할 때 해당 이미터 비트를 리팩터링하여 final 적절하게 출력할 수 있습니다. ES6)?

무언가에 대해 new 를 호출하는 것이 합법적인 경우 해당 항목에서 상속하는 것과 일대일 런타임 대응이 있습니다. new 'd가 될 수 있지만 super 'd가 아닌 것의 개념은 JavaScript에 존재하지 않습니다.

다시 말하지만, 커뮤니티에서 런타임에 final 를 적용하기 위해 여기에서 뭔가 마법을 부리기를 기대하고 있다고 생각하지 않습니다. 정확하게 언급했듯이 "JavaScript에는 존재하지 않습니다". 그러나 언급한 대로 컴파일 시간 제약으로 충분합니다.

TypeScript가 OOP 키워드 수프가 되는 것을 피하기 위해 최선을 다하고 있습니다. JavaScript에는 상속보다 더 나은 구성 메커니즘이 많이 있으며 C# 및 Java에 있는 모든 단일 키워드를 가질 필요 는 없습니다.

소프트웨어 개발 커뮤니티 전체에서 "상속보다 구성을 선호"하는 상당히 잘 알려진 문구입니다. 그러나 "호의"가 상속 을 포괄적인 설명으로 는 아닙니다 . 물론, C#과 Java에 있는 모든 단일 키워드가 _필요하지 않습니다_. 하지만 abstract 클래스("JavaScript에는 존재하지 않음")를 허용해야 하는 이유가 있어야 합니다. final 수업?

"should-be-final" 클래스에서 상속을 감지하기 위해 런타임 검사를 간단하게 작성할 수 있습니다. 모든 소비자가 TypeScript를 사용하는 것은 아니기 때문에 누군가 실수로 클래스에서 상속하는 것에 대해 "걱정"하는 경우 실제로 수행해야 합니다. .

C# 및 Java에 대해서도 마찬가지지만 컴파일러 수준에서 수행할 수 있는 sealed 및 final 이 있으므로 런타임 검사가 필요하지 않습니다.

내 모든 소비자가 TypeScript를 사용하지 않았다면 final 클래스에서 상속하는 것보다 더 많은 걱정거리가 생겼을 것입니다. 예를 들어 private 또는 protected 멤버에 대한 액세스, 정적 유형 검사 없음 또는 abstract 클래스 생성 기능.

TypeScript가 아닌 소비자가 가능한 한 안전한지 확인하기 위해 코드에 이러한 모든 항목(일부는 추가할 수조차 없음)에 대한 런타임 검사로 가득 차 있어야 합니까?

특정 클래스가 상속되지 않는 스타일 규칙을 적용하는 린트 규칙을 작성할 수 있습니다.

이것은 코드를 사용하는 사람이 린터를 실행하고 있다는 것을 의미하므로 여전히 적절한 솔루션이 아닙니다. 해결 방법입니다.

누군가가 "실수로" 봉인되어야 하는 클래스에서 상속받는 시나리오는 일종의 이상한 시나리오입니다. 나는 또한 주어진 클래스에서 상속받는 것이 "가능"한지 여부에 대한 누군가의 개별적인 평가가 아마도 다소 의심스럽다고 주장하고 싶습니다.

좋은/훌륭한 개발자는 클래스 확장과 같은 작업을 수행하는 근거에 대해 생각합니다. 그보다 적으면 이유를 제대로 이해하지 못한 채 "하지만 효과가 있다"는 사고방식을 갖게 됩니다.

can I로 시작하는 질문을 하는 것은 일반적으로 should I로 시작하는 질문보다 더 명확한 대답을 하는 경향이 있습니다.

기본적으로 클래스를 봉인하는 세 가지 이유는 보안, 성능 및 의도입니다. 그 중 두 가지는 TypeScript에서 의미가 없으므로 다른 런타임에서 수행하는 작업의 1/3만 수행하는 복잡성 대 이득을 고려해야 합니다.

틀림없이 나는 TypeScript가 보안과 의도 중 두 가지 이유를 실제로 충족할 것이라고 말하고 싶습니다. 그러나 이것이 순전히 컴파일 시간 검사로 구현된 경우 올바르게 지적하는 것이 아니라 컴파일러 수준 에서만 이 작업을 수행할 수 있습니다. , 런타임 수준에서.

final 가 없다고 해서 JavaScript 클래스를 효과적으로 사용하는 능력에 해를 끼치거나 JavaScript 클래스 없이는 사용할 수 없다고 생각하지 않습니다. 나는 final 가 "필요한" 기능이라기보다는 "있으면 좋은" 기능에 가깝다고 생각하지만 TypeScript의 많은 기능에 대해서도 마찬가지입니다.

여기서 주된 불만은 TypeScript를 사용하여 abstract 및 _open_ 클래스를 만들 수 있지만 상속 및 다형성 측면에서 우아하고 표현적인 방식으로 완전한 그림을 그릴 수 없다는 것입니다.

생성자를 숨기는 것은 클래스 구현에서 의미론적이고 표현적인 가치를 빼앗기 때문에 커뮤니티가 원하는 것이 아닙니다. 그리고 다시 한 번, 액세스 수정자는 "있으면 좋은" 것이기 때문에 런타임에 적용할 수도 없습니다. 본질적으로 "JavaScript에 존재하지 않는" 상황입니다.

개발자로서 나는 많은 모자를 가지고 있습니다. 현재 저는 C# 모자, Kotlin 모자 및 TypeScript 모자가 있습니다.

• Kotlin 모자를 쓰고 있으면 기본적으로 클래스가 final이기 때문에 final 에 대해 걱정할 필요가 없습니다.
• C# 모자를 쓰고 습관적으로 sealed 를 적용하여 소비자 가 I 를 묻는 대신 can I 을 묻도록 합니다 . 종종 C# 클래스는 실제로 sealed 이어야 하며 종종 간과됩니다.
• 내 TypeScript 모자를 쓴 상태에서 해결 방법으로 생성자를 숨겨야 합니다. 내(및 커뮤니티) 의견으로는 언어에 유용한 것이 부족하기 때문입니다.

흥미롭게도 TypeScript 팀이 테이블에 둘러앉아 abstract 수업에 대해 토론할 때 누군가 손을 들고 "하지만 final 어떻습니까?"라고 말했습니다.

@RyanCavanaugh 흠 당신의 요점을 이해합니다

대부분 오해였던 것 같아요(설명한 내용으로 추측)

@series0ne 요약은 우리의 의도가 JS에서 최종 클래스를 생성하도록 요청함으로써 타이프스크립트 출력을 너무 복잡하게 만들지 않고(이것이 그렇게 하려면 기차 사고가 될 것입니다) 단지 사람들에게 말하기 위한 추가 규칙을 생성하도록 요청하여 너무 복잡하지 않다는 것입니다. 그렇게 하세요. 그리고 API 사용자에게 출력이 아닌 타입스크립트 파일/컴파일러에서 해당 클래스(안정성, 보안상의 이유로 등)를 엉망으로 만들어서는 안 된다고 알려줍니다.

이 기능이 있으면 좋을 것 같습니까? 예, 몇 가지 기술을 수행할 수 있는 더 빠른 방법이 있으면 좋습니다.

정말 필요한가요? 실제로 이것은 사려깊은 사소한 것일 수 있으며 Typescript 팀이 이 추가 기능을 구현할 여유가 있다면 우선순위가 되어서는 안 됩니다.

final/sealed 키워드가 특히 버그 수정, 패치, 동작 변경과 같은 측면을 많이 복잡하게 만들 수 있다는 것을 알았습니다.

이것을 설명하면 모든 클래스가 확장되지 않도록 잠금으로써 final을 남용하는 것을 완전히 볼 수 있습니다. IMO를 도발하는 것은 **에서 처리해야 할 큰 고통입니다. "보안" 때문에 편집증에 빠져 있기 때문에 상속을 통해 사용자 클래스를 변경하기 위해 잠겨 있는 API를 사용하고 싶지 않습니다.

이것은 내가 필요에 맞게 이 클래스 동작을 변경할 수 있도록 하기 위해 프로토타입을 사용하고 별칭을 사용하거나 이 클래스를 재정의해야 함을 의미합니다.
이는 특히 해당 클래스에 추가 기능을 추가하고 파괴적인 워크플로를 사용하고 싶지 않은 경우 성가신 일입니다.

이 후에는 제가 지금 상황을 잘못 이해하고 있을지도 모르니 자유롭게 설명해주세요. :)

아, 제가 ES4에 대해 많이 읽었던 것을 기억한다면(초안이 프로덕션 단계에 있었을 때 제가 아직 어린아이였을지 확신이 서지 않습니다.) 놀랍게도 Typescript와 정말 비슷하게 생겼습니다.

초안 사양에 다음과 같이 나와 있습니다.
https://www.ecma-international.org/activities/Languages/Language%20overview.pdf

A class that does not explicitly extend any other class is said to extend the class Object. As a consequence, all the classes that exist form an inheritance hierarchy that is a tree, the root of which is Object. A class designated as final cannot be extended, and final methods cannot be overridden: class C { final function f(n) { return n*2 } } final class D extends C { function g() { return 37 } }

그래서 기술적으로 최종 키워드는 Ecmascript 4판으로 계획되었습니다. 우리는 JS의 미래 통합에서 그것을 보게 될 것입니다. 나는 그것에 대해 의심하지만 실제로 클래스를 통합하여 이것이 가능할 수도 있지만 누가 알겠습니까?

간신히 만난 한 가지 사용 사례가 있어 이 문제를 찾게 되었습니다. this 를 반환 유형으로 사용하는 것과 관련이 있습니다.

abstract class TileEntity {
    //constructor, other methods...
    abstract cloneAt(x: number, y: number): this;
}

이 글을 쓸 때 내 의도는 TileEntity가 불변(따라서 전달하기에 안전)하지만 주어진 TileEntity가 몇 가지 변경된 속성(이 경우 x 및 y 으로 복제될 수 있도록 하는 것입니다. ) 하위 클래스의 모양에 대해 알 필요가 없습니다. 그것이 내가 쓰고 싶은 것이지만 구현을 (올바르게) 작성하려고하면 이것이 중단됩니다.

class TurretTileEntity extends TileEntity {
    //constructor, other methods...
    cloneAt(x: number, y: number): this {
        return new TurretTileEntity(x, y, /* ... other properties */);
    }
}

문제는 TurretTileEntity의 하위 클래스가 _절대_ 없을 것이라고 선언할 수 없으면 this 반환 유형을 TurretTileEntity 유형으로 좁힐 수 없다는 것입니다.

반환 값을 <any> 캐스팅할 수 있다는 점을 고려하면 Typescript에서 이 단점의 영향은 최소화됩니다. 이것은 객관적으로 반패턴이며, 유형 시스템이 더 표현적일 수 있다는 유용한 표시입니다. 최종/봉인된 클래스가 지원되어야 합니다.

흥미롭게도 TypeScript 팀이 테이블에 둘러앉아 추상 클래스에 대해 논의할 때 손을 들고 "하지만 final은 어떻습니까?"라고 말하는 사람이 있습니까?

예. 키워드를 추가할 때마다 "하지만 다른 키워드도 추가해야 합니다!" 우리는 가능한 한 신중하게 언어를 성장시키고 싶기 때문에 추가에 대한 장점입니다. final 클래스 선언도 이 ​​진영에 있습니다. final 클래스가 있으면 final 메서드나 속성도 "필요"합니다. 스코프 크립처럼 보이는 모든 것은 극도의 의심으로 간주됩니다.

저는 최종 수업과 방법이 매우 중요하다고 생각합니다. 시행하시길 바랍니다.

이 문제는 최종/봉인된 클래스에 관한 것입니다. 완전히 다른 개념인 최종/봉인된 방법에 대한 주제에서 벗어난 토론이 있었습니다.

mhegazy는 이 문제에 찬성하여 https://github.com/Microsoft/TypeScript/issues/9264 를 닫았습니다. 최종/봉인된 방법을 추적하기 위해 속임수로 마감되지 않은 별도의 문제가 있습니까?

@crcla 위의 @RyanCavanaugh 의 의견 중 일부를 읽고 다른 문제를 닫는 근거는 final/sealed 클래스 지원이 final/sealed 메서드 지원을 포함하기 때문이라고 생각합니다. 둘은 상당히 밀접한 관련이 있는 주제입니다.

나는이에 대한 제안 믿을 수 없어 final 로 표시됩니다 Won't fix .

레이블을 다시 In Discussion 하고 구현하십시오!

제 경우에는 플러그인에 대한 추상 기본 클래스를 작성하고 플러그인 클래스가 실수로 내 기본 클래스 메소드를 덮어쓰지 않도록 하고 싶습니다. private constructor , Object.seal 것도 이 작업을 수행할 수 없습니다.

이것을 결정적인 기능으로 보는 사람들에게: 실제로는 그렇지 않습니다. API가 소비자가 확장해야 하는 클래스 구현을 노출하는 것으로 구성되어 있는 경우 이를 수행하는 더 좋은 방법이 있습니다. React의 나쁜 예를 따르지 마십시오. 그냥 함수와 간단한 객체를 사용하고 이 OO 넌센스는 그것이 속한 곳에 그대로 두십시오: 과거에.

이제 downvote를 가져오세요 😀

누군가이 토론이 최종 수업과 최종 방법을 구별하지 않는 방법을 설명해 주시겠습니까? 물론 일부 메서드가 재정의되는 것을 방지하면 엄청난 가치가 추가됩니다. 플러그인 개발자가 내 프레임워크 클래스의 일부를 서브클래싱하고 추상 기능을 구현하여 기능을 추가할 수 있는 가능성을 제공하고 싶습니다. 오류 처리/로그인/확인이 수행되는지 확인하십시오.

@pelotom OOP 구조와 패턴을 사용하고 싶지 않다면 하지 마세요. 아무도 그렇게 하라고 말하지 않습니다. 그러나 반대 방향으로도 동일하게 적용되어야 합니다. 누군가 OOP 구조를 사용하고 싶다면 그냥 두십시오.
다른 사람들이 특정(비 OOP) 패턴을 채택하도록 강제함으로써 OOP를 비난하는 것과 동일한 행동을 채택하게 됩니다. 적어도 일관성이 있습니다 :)

TypeScript에 final 키워드를 추가하는 것은 주요 변경 사항이 아니며 기존 프로젝트에 어떤 식으로든 영향을 미치지 않지만 @thorek , 저 및 다른 많은 사람들에게 중요한 기능이 될 것입니다.

누군가가 OOP 구조를 사용하고 싶다면 그냥 두십시오.

우리는 사람들이 OOP 구조를 사용해야 하는지 여부에 대해 토론하는 것이 아니라 현재 존재하지 않는 OOP 구조를 언어에 추가해야 하는지 여부에 대해 토론하고 있습니다. 그렇게 하면 다른 기능에 사용할 수 있는 개발자 시간이 걸리고 언어가 더 복잡해져서 향후 기능의 속도가 느려집니다(모든 새로운 기능에 대해 모든 이전 기능과 상호 작용하는 방식을 고려해야 하기 때문에). TypeScript의 개발 및 복잡성 예산을 더 유용한 일에 사용하고 싶기 때문에 확실히 영향을 미칩니다!

fwiw, 우리는 아마도 고객(google)이 @final 을 주석에 사용하여 클로저 컴파일러로 전파하도록 권장할 것입니다.

R&D 팀이 다른 팀에서 사용할 수 있는 TS 라이브러리를 빌드할 때 클래스 및 메서드에 _final_을 추가하면 유용합니다. 이러한 키워드는 그러한 도구의 서비스 노출 안정성의 (중요한) 일부입니다.
키워드는 대규모 팀에서는 더 중요하고 소규모 프로젝트에서는 덜 중요합니다. imho.

@dimiVergos 이것은 정확히 제 경우이며 다른 많은 사람들도 마찬가지라고 가정합니다. 내 위치 때문에 편향된 것처럼 보일 수 있다고 상상할 수 있지만, 내 경험에 따르면 이 키워드의 정당한 사용은 이 키워드의 유일한(비록 높긴 하지만) 정당한 것 같습니다.

나는 이것에 대한 수정에 열려 있습니다!

나는 final 클래스보다 final 메소드를 지원하는 데 더 신경을 씁니다. 투표하기에 적합한 티켓입니까? 티켓 https://github.com/Microsoft/TypeScript/issues/9264가 그렇게 암시하는 것 같습니다.

그렇다면 "최종 방법"에 투표하려면 어떻게 해야 합니까? 아니면 이 댓글로 제가 투표한 건가요? 또한 제목에 "메서드"를 어떻게 추가합니까? 그냥 수정해도 될까요? 현재 제목은 오해의 소지가 있는 클래스에만 국한되어 있지만 토론에는 메서드도 포함됩니다.

다른 많은 사람들과 마찬가지로 TypeScript에서 최종 메서드를 보고 싶습니다. 나는 실패에 영향을 받지 않지만 최소한 약간은 도움이 되는 부분적 해결 방법으로 다음 접근 방식을 사용했습니다.

class parent {
  public get finalMethod(): () => void {
    return () => {
      // final logic
    };
  }
}

class child extends parent {
  // ERROR "Class 'parent' defines instance member accessor 'finalMethod', but extended class 'child' defines it as instance member function"
  public finalMethod(): void { }
}

다음은 final 메서드에 대한 또 다른 실제 사용 사례입니다. React.Component 의 다음 확장을 고려하여 간단한 Context 를 더 쉽게 구현할 수 있습니다.

interface FooStore{
  foo: string;
}

const {Provider, Consumer} = React.createContext<FooStore>({
  foo: 'bar';
});

abstract class FooConsumerComponent<P, S> extends React.Component<P, S> {

  // implement this instead of render
  public abstract renderWithStore(store: FooStore): JSX.Element;

  public final render() {
    return (
      <Consumer>
        {
          (store) => {
            return this.renderWithStore(store);
          }
        }
      </Consumer>
    );
  }
}

render() 메서드에 final 없으면 메서드를 잘못 재정의하여 모든 것을 손상시키는 것을 막을 수 없습니다.

안녕하세요, 다른 많은 사람들처럼 적어도 방법에 대해 "최종" 또는 "봉인된" 키워드를 원합니다. 이 키워드는 개발자가 라이브러리 고객이 중요한 코드 블록(예: 플러그인)을 확장하는 것을 방지할 수 있게 해주기 때문에 이 키워드가 정말 부가 가치라는 데 전적으로 동의합니다.

내가 찾은 유일한 해결 방법은 다음과 같은 메서드 데코레이터를 사용하는 것입니다.
function sealed(target, key,descriptor){ descriptor.writable = false; // Prevent method to be overriden }

그런 다음 "기본"클래스에서 데코레이터를 사용하여 메서드 재정의를 방지합니다. 예:

class MyBaseClass {
<strong i="10">@sealed</strong>
public MySealedMethod(){}

public OtherMethod(){}

...
}

이런 식으로 'MySealedMethod'는 하위 클래스에서 (쉽게) 재정의될 수 없습니다. 예:

class AnotherClass extends MyBaseClass {
public MySealedMethod(){} ====>> ERROR at RUNTIME (not at compile time)
}

실제로, 이 해결 방법의 유일한 단점은 "봉인된"이 런타임에만 표시되지만(자바스크립트 콘솔의 오류) 컴파일 시간에는 표시되지 않는다는 것입니다(메소드 속성이 함수를 통해 설정되기 때문에)

@RyanCavanaugh

예. 키워드를 추가할 때마다 "하지만 다른 키워드도 추가해야 합니다!" 우리는 가능한 한 신중하게 언어를 성장시키고 싶기 때문에 추가에 대한 장점입니다.

이 기능에 반대하는 마음으로 이 논쟁을 시작하는 것 같습니다. 인기있는 기능은 그러한 기능을 고려하는 것에 대한 포인트가 되어서는 안됩니다. _왜 인기가 있는지_ 스스로에게 물어보고 신중하게 고려하는 것이 중요합니다.

나는 당신이 그것에 대해 논의했다고 확신하고 그것을 고려하거나 반대하는 논쟁이 떠돌았습니다. 그것에 대한 주장은 단지 기능 크리프입니까, 아니면 더 구체적인 것이 있습니까? 당신은 그것을 프린지 기능이라고 생각합니까? 그렇다면 마음을 바꾸기 위해 우리가 뭔가를 할 수 있습니까?

우리 모두가 숙고할 수 있도록 이 질문을 여기에 남겨두겠습니다.

현재 구성을 사용하여 _디자인에 의해_ 클래스를 봉인하는 방법이 있습니까?
기능이 추가되면 새로운 작업을 수행할 수 있습니까? (에서와 같이 존재하는 구성이 허용하지 않음)
기능을 통해 새로운 작업을 수행할 수 있었다면 가치 있는 작업입니까?
봉인된 클래스를 추가하면 언어 복잡성이 너무 많이 증가합니까?
봉인된 클래스를 추가하면 컴파일러 복잡성이 너무 많이 증가합니까?

이것들을 논의할 목적으로, 나는 논의에 봉인된 메서드를 포함하지 않고 구현에 런타임 검사도 포함하지 않습니다. 우리 모두는 이것을 자바스크립트에서 시행할 수 없다는 것을 이해합니다.

참고: 이 기능에 대한 카운터가 기능 크리프에 대한 포괄적인 설명보다 조금 더 많았다면 정말 좋았을 것입니다.

@asimonf 나는 당신이 말한 모든 것이 이미 이 댓글 ("더 보기" 섹션을 확장해야 볼 수 있음)과 그 다음

여기서 무엇이 우리의 마음을 바꾸겠습니까? sealed 키워드가 없기 때문에 제대로 작동하지 않는 코드의 예를 보여주는 사람들.

여기서 키워드가 해결하려고 시도하는 시나리오는 누군가가 실수로 클래스에서 상속하는 시나리오입니다. 어떻게 실수로 클래스에서 상속합니까? 하기 쉬운 실수가 아닙니다. JavaScript 클래스는 본질적으로 취약하므로 모든 하위 클래스 가 기본 클래스의 동작 요구 사항을 이해해야

처음부터 거기에 가지 말라고 말하는 최소한 두 개의 개별 장애물에 직면했어야 하는 상황이 이미 상황인데 TypeScript에 이 키워드가 있어야 하는 이유는 무엇입니까?

나는 거의 영원히 프로그래밍을 해왔고 나는 그것이 봉인되었고 시도하지 말았어야 했다는 것을 알기 위해 무언가를 서브클래싱하려고 시도한 적이 없습니다. 내가 슈퍼 천재라서가 아니야! 매우 드문 실수이며 JavaScript에서 이러한 상황은 이미 기본 클래스에 대해 먼저 질문해야 하는 상황입니다. 그래서 어떤 문제 가 해결 되고 있습니까?

내가 final을 사용하는 실제 경우는 수퍼 메소드를 호출하지 않는 것으로 메소드를 재정의하는 것을 방지하는 것입니다. 물론 일부 공개 방법. 그러나 내가 알아낸 진정한 해결책은 모든 하위 메서드가 슈퍼 메서드를 호출하도록 강제하는 기능입니다. https://github.com/Microsoft/TypeScript/issues/21388

나는 언어 디자이너가 아니기 때문에 언어에 키워드를 추가하는 단점에 대해 말할 수 없습니다. 나는 현재 내가 최종적으로 의도한 메소드가 있는 추상 수퍼클래스에 대해 작업하고 있다고 말하지만, 실망스럽게도 그렇게 할 수 없다는 것을 알게 되었습니다. 지금은 댓글을 추가하는 이상적이지 않은 접근 방식을 사용하지만 클래스를 구현하는 팀 구성원은 해당 댓글을 읽지 않을 수 있습니다.

위에 final 가 유용할 뿐만 아니라 구축 중인 플랫폼에 _실제 가치_와 _실제 안전_을 제공할 때/어디서에 대한 훌륭한 예가 많이 있다고 생각합니다. 나에게도 다르지 않다. 내가 말했듯이, 나는 언어 디자인의 복잡성에 대해 많이 알지 못하지만 이것은 분명히 사람들이 원하거나/사용할/나는 그것을 남용하거나 나쁜 코드를 생성할 방법을 볼 수 없는 기능입니다. 나는 범위 크리프를 두려워한다는 개념을 이해하지만 TS 개발자는 커뮤니티가 원하는 모든 것을 구현할 필요가 없습니다.

토론에 제 의견을 덧붙이자면, 이 문제는 기능 추가를 지지하는 좋은 논거로 가득 차 있기 때문에 찬성측으로 제 엄지손가락을 놓고 싶습니다.

• 스코프 크립으로 이어질 수 있음(관리 가능)
• 사람들은 다른 기능을 요구할 것입니다.
• 효율성이 떨어질 수 있습니다.
• "OOP 개념을 사용하지 마십시오"라는 의견

위의 어떤 것도 TS 에코시스템 자체에 대한 신뢰할 수 있는 위협이나 여기에서 생성된 코드처럼 보이지 않습니다. 그것들은 모두 정치적인 것처럼 보입니다(아마도 효율성을 제외하고는, 하지만 저는 여러분을 크게 신뢰하고 있으므로 그것에 대해 걱정하지 않습니다. 게다가 약간의 효율성 감소는 무의식적으로 상속 실수로 중요한 구성 요소/라이브러리 구성을 폭파시키지 않을 가치가 있을 것입니다) .

이것이 건설적이기를 바랍니다! TS를 사랑하고 계속 개선되는 모습을 보고 싶습니다!

👍

--편집하다--

@RyanCavanaugh에 대한 응답:

So what problem is being solved?

해결되고 있는 문제는 위의 많은 의견에 의해 요약되어 있다고 생각합니다. 나는 이것을 모욕으로 의미하지 않지만 그 질문은 당신이 제시된 주장에 실제로 주의를 기울이지 않고 있고 당신의 마음이 "아니오"로 설정되어 있는 것처럼 나에게 들리게 합니다. 나는 그것에 대한 무례함을 의미하지 않습니다. 솔직히 말해서, 이 스레드는 이것이 해결할 수 있는 문제의 예들로 가득 차 있다는 것입니다.

어떻게 든 나는 기능 추가에 대한 심각한 우려를 아주 잘 설명하고 나에게 의미가 있는 이 의견을 놓쳤습니다. 다시 말하지만, 추가하는 것의 복잡성은 모르지만 효율성 문제는 제쳐두고(개발자가 TS 효율성에 대해 걱정하는 것이 아니므로 TS 팀의 작업임) final에 대한 좋은 주장은 없는 것 같습니다. (최소한 내 의견으로).

최근 논의의 대부분은 최종 방법 에 중점을 두었습니다(최종 수업에서는 덜). 최종 방법은 확실히 나의 주요 관심사입니다. @RyanCavanaugh 의 이전 게시물에서 "이 의견" 링크를 확장하면 그가 최종 방법 토론을 주제에서 벗어난 것으로 간주한다는 것을 방금 알아차렸습니다. 그러나 @mhegazy 는 이 티켓이 올바른 장소 방법 을 요청/투표해야 하는 위치에 대해 당황스럽습니다. 안내해 주시면 감사하겠습니다.

@cbutterfield
모순은 나도 알아차 렸지만 욕설 이 두려워 내 게시물에서 지적하지 않은 것입니다.
@RyanCavanaugh
@mhegazy
위의 주석에 따르면 최종 방법을 논의하기에 올바른 장소는 _is_입니다. 왜냐하면 그것이 실제로 제가 가장 관심이 있는 것이기 때문입니다.

많이 다운된 댓글을 되돌아보면(아직 추가하지 않았다면 👎를 추가하세요!) React가 class 기반 API를 강제로 사용하여 나쁜 예를 설정하지 _더 이상_ 하지 않는다는 사실을 보고하게 되어 기쁩니다. 사용자에! Hooks 제안을 통해 React 팀은 정신을 차리고 근본적으로 단순한 기능적 접근 방식을 수용했습니다. 그것으로 많은 개발자들이 클래스를 사용해야 하는 마지막 이유가 사라졌고 잘 해결되었습니다. 다시 말하지만, 수업이 필요하다고 생각하는 모든 것은 수업 없이 더 잘 수행될 수 있습니다 .

JS와 TS의 미래는 클래스가 없다, 찬양하라!

@cbutterfield 나도 알아차렸고 이 문제에서 #9264 문제가 논의되지 않았다면 제목이 Suggestion: Final keyword for classes and methods 변경되어야 한다고 생각합니다. 그렇지 않으면 최종 방법을 찾는 사람들이 (독점적으로) 첫 번째 게시물.

@mhegazy 인용 :
Java 및/또는 C#은 final 클래스를 사용하여 특수화되지 않을 것임을 알고 런타임에 클래스를 최적화합니다. 이것이 내가 주장하는 최종 지원의 주요 가치입니다. TypeScript에는 final이 없는 것보다 더 나은 코드 실행을 위해 제공할 수 있는 것이 없습니다.

나는 근본적으로 동의하지 않는다. 저는 여러 팀에서 수년간 Java로 개발했으며 런타임 최적화를 위해 최종 클래스나 메서드를 사용한 적이 없습니다. 실제로 이것은 주로 OOP 디자인 관용구입니다. 때로는 함수를 보호 및 보장하거나 라이브러리의 API 노이즈를 필수 요소로 제한하거나 API 사용자가 복잡한 API를 오해하지 않도록 보호하기 위해

예, 이러한 문제는 주석이나 인터페이스를 추가하여 해결할 수 있지만 final 는 깨끗하고 확장 가능한 API가 있는 간단한 클래스만 원하는 경우 필요한 기능으로 보이는 API를 줄이는 우아한 솔루션입니다.

이 문제는 거의 3년이 지났지만 이미 abstract 키워드가 있으므로 실제로 final 키워드가 있어야 합니다.

우리는 사람들이 그것을 사용하도록 강요하고 싶지 않으며 추상 키워드만큼 유용한 기능임을 명심하십시오. 그러나 final 키워드의 이점을 강력하게 보여주는 또 다른 사용 사례가 있습니다.

abstract class A {
  protected abstract myVar: string;

  protected abstract myFunction(): void;
}

class B extends A {
  protected readonly myVar: string = "toto";

  constructor() {
    super();
    this.myFunction();
  }

  protected myFunction() {
    console.log(this.myVar);
  }
}

class C extends B {
  constructor() {
    super();
  }

  protected myFunction() {
    console.log("tata");
  };

  public callFunction = () => {
    this.myFunction();
  }
}

const myB = new B(); // toto

const myC = new C(); // toto
myC.callFunction(); // tata

컴파일 후 결과:

toto
tata

따라서 이 코드에는 추상 메서드와 속성이 있는 추상 클래스 A 가 있습니다. 상속된 클래스에서 이를 정의하기를 원하지만 다른 클래스가 이러한 구현을 재정의하지 못하도록 하고 싶습니다.
우리가 할 수 있는 최선은 protected 키워드를 유지하는 것이지만, 보시다시피 여전히 속성을 재정의할 수 있습니다.

Typescript 컴파일 과정을 더 진행하고 readonly 를 사용하여 속성을 보호하면(그리고 메서드가 속성인 척) 어떻게 될까요?

class B extends A {
  [...]

  protected readonly myFunction = () => {
    console.log(this.myVar);
  }
}

class C extends B {
  protected myVar: string = "I am not protected that much";
  [...]

  protected myFunction = () => { // using the readonly keyword doesn't prevent any modification
    console.log("tata"); // If you launch this code, tata will still be logged in the console.
  };
}

(코드는 tsc로 컴파일되며 컴파일하거나 실행할 때 오류가 발생하지 않습니다)
이제 두 가지 문제가 있습니다.

• 우리는 B 속성을 보호하지 않으므로 예기치 않은 상속을 방지할 방법이 필요합니다.
• 이제 우리는 우리가 어떤 무시할 수 있다는 것을 알고 readonly , 그 클래스를 확장하여 속성을하고 YES, 타이프 라이터는 우리가 사용하는 것으로 변경하고 부모 속성의 것을 알고 private 대신 protected C 클래스는 동일한 액세스 유형/가시성이 아니므로 오류가 발생합니다.

현재 우리는 데코레이터(공식 Typescript 문서와 같이 봉인된 또는 최종 데코레이터 )를 사용할 수 있지만 런타임에서만 유용하며 대신 컴파일 프로세스에서 이를 방지해야 한다는 것을 기억하십시오.

보호된 읽기 전용 값을 재정의하려고 할 때 "보안 위반"(이를 호출할 수 있는 경우)에 대한 문제가 있는지 살펴보고 실제로 할 수 있고 해서는 안 됩니다. 그렇지 않으면 상속 항목이 있는 private , protected 키워드 중 private readonly 키워드의 검증에 대해 토론하는 문제를 열겠습니다.

ㅜㅜ ; dr : final 키워드는 두 가지 문제를 해결합니다( readonly 확인은 무단 재작성을 방지하는 좋은 시작이 될 것입니다)

3년 후.. 너무 웃기네요.

이 기능의 필요성을 증명하기 위해 다른 언어에서 수행된 작업을 살펴보는 것이 좋습니다.

Java:
final class SomeClass { ... }
PHP:
final class SomeClass { ... }
C#:
sealed class SomeClass {...}
C++:
class SomeClass final { ... }
Delphi:
type SomeClass = class sealed() ... end;

그래서 우리는 가장 인기 있는 모든 OOP 언어에서 이 기능이 OOP의 상속 논리에서 왔기 때문에 존재한다는 것을 알 수 있습니다.

또한 TS의 Dev 리드의 말을 인용해야 합니다.

최종 클래스가 있는 경우 최종 메서드나 속성도 "필요"합니다.

아이러니한 것인지 확실하지 않지만 JS에서는 readonly 키워드가 속성(그리고 속임수를 사용하는 경우 메서드)에 사용되므로 꽤 멍청한 요점입니다.

그리고 한 사람이 +40개의 downvotes를 가지고 있을 때 문제를 닫지 못하게 하는 것은 커뮤니티가 그에게 강하게 동의하지 않는다는 것을 의미하는 더 어리석은 상황을 피하기 위한 좋은 조언이 될 것입니다.

Typescript의 주요 기능을 강화하는 데 관심이 없다면 기술 뉴스가 Twitter에서 이를 전달할 수 있도록 큰 소리로 말하십시오. 그렇지 않으면 숨겨진 나쁜 소문일 뿐입니다. 당신은 단지 당신의 커뮤니티를 무시하고 있고 커뮤니티가 우리가 필요로 하는 것인지 아닌지를 검증하는 과정이 없습니다.

커뮤니티가 그에 대해 강하게 동의하지 않는다는 의미인 +40 downvotes가 있을 때 한 사람이 문제를 종료하지 못하게 하는 것은 더 어리석은 상황을 피하기 위한 좋은 조언이 될 것입니다.

나는 "한 사람"이 아닙니다. 여기에서 결정을 내릴 때 TypeScript 팀 전체의 의사 결정 프로세스가 반영됩니다. 디자인 팀은 이 문제를 여러 번 검토했으며 매번 동일한 결론에 도달했습니다. 당신은 그 결과에 동의하지 않는 것을 환영하지만, 그 과정은 논쟁의 대상이 아닙니다.

당신은 커뮤니티가 우리에게 필요한지 아닌지를 검증하는 과정이 없습니다.

이것은 바로 여기 과정이다 : 당신은 "바보"우리의 추론 내 요약을 호출하고 나를 (그리고 팀의 다른 사람들)를 읽고. 피드백을 듣고 있습니다.

다른 구현된 기능을 언급하는 이유가 이것이 냄새일 뿐 논쟁의 여지가 없다고 생각하는 이유는 알고 있지만 유형 앨리어싱 메커니즘이 고려되고 추가되었다는 것은 아이러니한 일입니다. ) 그러나 이와 같은 것은 거부됩니다.

결국 그런 기능이 없어도 살 수 있겠지만, TS가 갖고 있는 기능의 절반 정도도 마찬가지라고 할 수 있다. 그렇다면 이것을 구현하는 것을 고려하는 적절한 이유는 무엇입니까?

GitHub는 여기에 도움이 되지 않는 많은 댓글을 숨기므로 과거에 제공한 다양한 응답(추가 사항 포함)을 다시 게시합니다. 아래에 몇 가지 생각을 추가합니다.

지난 번 검토할 때 몇 가지 점을 고려했습니다.

• 클래스는 TYPESCRIPT 기능이 아니라 JAVASCRIPT 기능 입니다. final 없으면 수업이 완전히 무용지물이라고 생각되면 TC39 위원회와 상의하거나 es-discuss에 제출해야 합니다. final 가 필수 기능이라고 TC39에게 확신을 줄 수 있는 사람이 없다면 TypeScript에 추가하는 것을 고려할 수 있습니다.
• 무언가에서 new 를 호출하는 것이 합법적인 경우 해당 항목에서 상속하는 것과 일대일 런타임 대응이 있습니다. new 'd가 될 수 있지만 super 'd가 아닌 무언가의 개념은 JavaScript에 존재하지 않습니다.
• TypeScript가 OOP 키워드 수프가 되는 것을 피하기 위해 최선을 다하고 있습니다. JavaScript에는 상속보다 더 나은 구성 메커니즘이 많이 있으며 C# 및 Java에 있는 모든 단일 키워드를 가질 필요 는 없습니다.
• "should-be-final" 클래스에서 상속을 감지하기 위해 런타임 검사를 간단하게 작성할 수 있습니다. 모든 소비자가 TypeScript를 사용하는 것은 아니기 때문에 누군가 실수로 클래스에서 상속하는 것에 대해 "걱정"하는 경우 실제로 수행해야 합니다. .
• 특정 클래스가 상속되지 않는 스타일 규칙을 적용하는 린트 규칙을 작성할 수 있습니다.
• 누군가가 "실수로" 봉인되어야 하는 클래스에서 상속받는 시나리오는 일종의 이상한 시나리오입니다. 나는 또한 주어진 클래스에서 상속받는 것이 "가능"한지 여부에 대한 누군가의 개별적인 평가가 아마도 다소 의심스럽다고 주장하고 싶습니다.
• 기본적으로 클래스를 봉인하는 세 가지 이유는 보안, 성능 및 의도입니다. 그 중 두 가지는 TypeScript에서 의미가 없으므로 다른 런타임에서 수행하는 작업의 1/3만 수행하는 복잡성 대 이득을 고려해야 합니다.

TS가 필요하지 않은 이유에 대한 설득력 있는 주장을 듣지 못했습니다.

이것이 작동하는 방식이 아님을 상기하십시오. 모든 기능은 -100 에서 시작 합니다. 해당 게시물에서

이러한 질문 중 일부에서 질문은 특정 기능을 "제거"하거나 "제외"한 이유를 묻습니다. 이 문구는 기존 언어(C++ 및 Java가 여기에서 인기 있는 선택임)로 시작한 다음 원하는 지점에 도달할 때까지 기능을 제거하기 시작했음을 의미합니다. 그리고 일부 사람들에게는 믿기 어려울 수 있지만 언어는 그렇게 설계되지 않았습니다.

우리는 유한한 복잡성 예산을 가지고 있습니다. 우리가 하는 모든 일은 다음에 하는 모든 일을 0.1% 느리게 만듭니다. 기능을 요청하면 다른 모든 기능이 조금 더 어려워지고, 조금 느려지고, 가능성이 조금 낮아질 것을 요청하는 것입니다. Java가 있기 때문에 또는 있기 때문에 또는 되고 명령줄 스위치를 추가할 수 있기 때문에 여기에는 아무 것도 들어가지 않습니다 . 기능은 자신과 미래에 대한 전체 부담에 대한 비용을 지불해야 합니다.

여기서 무엇이 우리의 마음을 바꾸겠습니까? final 키워드가 없기 때문에 제대로 작동하지 않는 코드의 예를 보여주는 사람들.

여기서 키워드가 해결하려고 시도하는 시나리오는 누군가가 실수로 클래스에서 상속하는 시나리오입니다. 어떻게 실수로 클래스에서 상속합니까? 하기 쉬운 실수가 아닙니다. JavaScript 클래스는 본질적으로 취약하므로 모든 하위 클래스 가 기본 클래스의 동작 요구 사항을 이해해야

다시 말해 , JavaScript에서 클래스를 상속하는 유일한 올바른 프로세스는 항상 해당 클래스의 문서를 읽는 것으로 시작됩니다 . 기본 클래스가 단순히 코딩을 파생하고 시작해야 하는 제약 조건이 너무 많습니다. 첫 번째 단계 에서 시도하지 말아야 한다는 것을 이미 알고 있어야 하는 경우 3단계에서 제공하는 정적 시행은 어떤 가치를 제공합니까?

처음부터 거기에 가지 말라고 말하는 적어도 두 개의 개별 장애물에 직면했어야 하는 상황이 이미 상황인데 TypeScript에 이 키워드가 있어야 하는 이유

나는 거의 영원히 프로그래밍을 해왔고 나는 그것이 봉인되었고 시도하지 말았어야 했다는 것을 알기 위해 무언가를 서브클래싱하려고 시도한 적이 없습니다. 내가 슈퍼 천재라서가 아니야! 매우 드문 실수이며 JavaScript에서 이러한 상황은 이미 기본 클래스에 대해 먼저 질문해야 하는 상황입니다. 그래서 어떤 문제 가 해결 되고 있습니까?

Typescript의 주요 기능을 강화하는 데 관심이 없다면 기술 뉴스가 Twitter에서 전달할 수 있도록 크게 말해 주세요.

우리는 언어를 디자인하는 방법에 대해 매우 명시적입니다 . 비목표 번호 1은 이 제안에 정확히 말합니다.

여기에 있는 많은 댓글을 읽은 후의 개인적인 반응은 다른 언어에 존재하는 구성으로 인해 강력한 편향 효과가 있다는 것입니다. 백지 상태의 관점에서 접근하면 상상할 수 있는 수십 가지 동작이 있으며 그 중 TypeScript에는 작은 하위 집합만 있습니다.

메소드에 적용되고 파생된 메소드가 super 를 통해 호출하도록 강제한 일부 키워드를 쉽게 상상할 수 있습니다. C#과 Java에 이 키워드가 있다면 사람들은 이 키워드가 맞는 곳에 절대적으로 적용할 것입니다. 사실, 런타임 검사를 적용하는 것이 불가능하고 "파생 클래스가 존재하지 않을 수 있다"보다 기본 파생 계약의 훨씬 더 미묘한 측면이기 때문에 틀림없이 final 보다 훨씬 더 일반적으로 시행됩니다. ". final 가 아닌 다양한 방식으로 유용할 것입니다. 나는 이 키워드보다 그 키워드를 훨씬 더 선호합니다(복잡성 대 가치 기준을 충족하지 못한다고 생각하지만).

그렇다면 이것을 구현하는 것을 고려하는 적절한 이유는 무엇입니까?

피드백을 볼 때 강력한 고려 사항은 다음과 같습니다.

• 이 JavaScript 라이브러리의 동작을 적절하게 표현할 수 없습니다.
• 내 코드가 컴파일되었지만 이 (미묘한) 오류가 있기 때문에 실제로는 없어야 합니다.
• 이 코드의 의도는 유형 시스템에서 적절하게 전달되지 않습니다.

final 는 이것들을 적중하지만 "이 함수는 연속으로 두 번 호출될 수 없습니다" 또는 "이 클래스의 생성은 다음 비동기 틱까지 실제로 완료되지 않습니다"라는 수정자도 마찬가지입니다. 상상할 수 있는 모든 것이 존재해서는 안 됩니다.

"실제로 하위 분류할 수 없는 클래스에서 상속하려고 했기 때문에 디버깅에 몇 시간을 소비했습니다"와 같은 피드백을 본 적이 없습니다. 누군가는 실제로 상상할 수 없기 때문에 '와트'를 올바르게 트리거할 것이라고 말했습니다. 수정자가 존재하더라도 실제로 상황에 도움이 되지 않을 것입니다. 라이브러리는 클래스가 최종 클래스인지 문서화하지 않기 때문입니다. 예를 들어 fs.FSwatcher final 입니까? 노드 작성자도 모르는 것 같습니다. 따라서 작성자가 final 라는 것을 알고 있으면 final 이면 충분하지만 이는 관계없이 문서화될 것이며 final 의 부족은 실제로 아무 것도 알려주지 않습니다. 단순히 어느 쪽이든 알려져 있지 않습니다.

전체 블록을 읽고 기능 선택에 대한 팀의 진술을 이해합니다. 내 의견에서 특정 요점으로 돌아가겠습니다.

나는 "한 사람"이 아닙니다. 여기에서 결정을 내릴 때 TypeScript 팀 전체의 의사 결정 프로세스가 반영됩니다.

죄송합니다. mhegazy와 그가 Typescript를 사용하는 커뮤니티에서 받은 꽤 방대한 피드백을 언급하고 있었습니다.

final이 없으면 수업이 완전히 무용지물이라고 생각되면 TC39 위원회와 상의하거나 es-discuss에 제출해야 합니다. 아무도 final이 필수 기능이라는 것을 TC39에게 확신시키거나 설득할 수 없다면 TypeScript에 추가하는 것을 고려할 수 있습니다.

private 키워드에 대한 제안이 이미 있으므로 final 가 첫 번째 단계라고 생각하지 않습니다. https://github.com/tc39/proposal-private-methods

나는에 대해 회의 해요 You should a comment to say *dont do this* , 그것은 양식에 말처럼 Hey don't write down specific characters 당신이 N ° dev에의 한 규칙을 알아야한다, 그래서 당신은 거의 영원히 년 동안 코딩 : (사용자를 신뢰하지 마십시오 코드를 사용할 개발자)

나는 우리가 모든 것을 절대적으로 중지하고 최종 키워드를 구현하기 위해 10억 달러를 투자해야 한다고 말하는 것이 아닙니다. 사용 사례가 너무 낮아서 효율적이지 않기 때문입니다. 또한 제한이 TS와 JS 모두에 있는 몇 가지 예를 제시했다는 점을 고려하십시오. 사람들이 TS를 선택하면 런타임이 아닌 컴파일 시간에 오류를 방지하기 위한 것입니다. 런타임에 일이 터지기를 원한다면 JS를 사용하고 TS에 대한 관심을 멈출 수 있지만 그게 요점이 아닙니다. final 키워드를 사용하는 방법을 보여주는 궁극적인 사용 사례가 있기 때문입니다. I want to lock 방법, 나는 누군가가 그것을 재정의하는 것을 원하지 않습니다.

그리고 Javascript가 이에 의해 제한되어 있기 때문에 커뮤니티는 Typescript가 그 한계를 넘어설 수 있다고 생각했습니다. 그래서 이 문제가 3년 동안 지속되어 왔습니다. 그래서 사람들은 여전히 ​​이 기능이 없는 이유를 궁금해하고 있습니다. 그래서 우리는 컴파일러를 원합니다. 클래스 및/또는 메서드의 수동 검사를 수행합니다.

# 키워드와 함께 포함하는 제안이 실제로 있지만 JS가 private/public 메서드를 구현하기를 기다리지 않았습니다( public / private 보다 덜 장황합니다. ), 완벽이란 더 이상 아무것도 추가할 수 없을 때가 아니라 더 이상 아무것도 제거할 수 없을 때이기 때문에 완벽한 언어를 만들고 싶었습니다.

컴파일 프로세스에서 메서드가 덮어쓰여지는 것을 방지하는 솔루션을 찾을 수 있다면(요점이 유효하지 않기 때문에 런타임 프로세스에서는 아님) 제 게스트가 되어주세요.

나는 상황의 약점(클래스가 아닌 메서드/속성에 대해)을 보여주려고 노력했습니다. 왜냐하면 모든 TS 개발자는 원하는 라이브러리를 다시 작성할 수 있고 원하는 모든 것을 깨뜨릴 수 있기 때문입니다. 아마도 그것이 바로 그 아름다움일 것입니다.

그건 그렇고, 답변에 감사드립니다. 개발팀이나 당신을 향한 증오나 나쁜 행동은 없습니다.

모든 유효 포인트! 그러나 다음과 같이 토론을 나누도록 합시다.

a) 최종 수업 지원
b) 최종 방법 지원

모든 인수가 a)를 대상으로 하는 동안 - 아무 대상도 b를 대상으로 하지 않습니다.

토론에서 여러 번 지적했듯이 최종 방법을 갖는 것이 중요합니다. 지금까지 내가 들은 유일한 대답은 "OOP를 하지 말라"는 것이었습니다. 하지만 그것은 저와 다른 많은 사람들이 동의할 수 있는 사항이 아닙니다.

Am 28.01.2019 um 20:32 schrieb Ryan Cavanaugh [email protected] :

GitHub는 여기에 도움이 되지 않는 많은 댓글을 숨기므로 과거에 제공한 다양한 응답(추가 사항 포함)을 다시 게시합니다. 아래에 몇 가지 생각을 추가합니다.

지난 번 검토할 때 몇 가지 점을 고려했습니다.

클래스는 JAVASCRIPT 기능이지 TYPESCRIPT 기능이 아닙니다. final이 없으면 수업이 완전히 무용지물이라고 생각되면 TC39 위원회와 상의하거나 es-discuss에 제출해야 합니다. 아무도 final이 필수 기능이라는 것을 TC39에게 확신시키거나 설득할 수 없다면 TypeScript에 추가하는 것을 고려할 수 있습니다.
무언가에 대해 new를 호출하는 것이 합법적인 경우 해당 항목에서 상속하는 것과 일대일 런타임 대응이 있습니다. 새로운 것이 될 수 있지만 슈퍼가 아닌 것에 대한 개념은 JavaScript에 존재하지 않습니다.
TypeScript가 OOP 키워드 수프가 되는 것을 피하기 위해 최선을 다하고 있습니다. JavaScript에는 상속보다 더 나은 구성 메커니즘이 많이 있으며 C# 및 Java에 있는 모든 단일 키워드를 가질 필요는 없습니다.
"should-be-final" 클래스에서 상속을 감지하기 위해 런타임 검사를 간단하게 작성할 수 있습니다. 모든 소비자가 TypeScript를 사용하는 것은 아니기 때문에 누군가 실수로 클래스에서 상속하는 것에 대해 "걱정"하는 경우 실제로 수행해야 합니다. .
특정 클래스가 상속되지 않는 스타일 규칙을 적용하는 린트 규칙을 작성할 수 있습니다.
누군가가 "실수로" 봉인되어야 하는 클래스에서 상속받는 시나리오는 일종의 이상한 시나리오입니다. 나는 또한 주어진 클래스에서 상속받는 것이 "가능"한지 여부에 대한 누군가의 개별적인 평가가 아마도 다소 의심스럽다고 주장하고 싶습니다.
기본적으로 클래스를 봉인하는 세 가지 이유는 보안, 성능 및 의도입니다. 그 중 두 가지는 TypeScript에서 의미가 없으므로 다른 런타임에서 수행하는 작업의 1/3만 수행하는 복잡성 대 이득을 고려해야 합니다.
TS가 필요하지 않은 이유에 대한 설득력 있는 주장을 듣지 못했습니다.

이것이 작동하는 방식이 아님을 상기하십시오. 모든 기능은 -100 https://blogs.msdn.microsoft.com/ericgu/2004/01/12/minus-100-points/ 에서 시작합니다. 해당 게시물에서

이러한 질문 중 일부에서 질문은 특정 기능을 "제거"하거나 "제외"한 이유를 묻습니다. 이 문구는 기존 언어(C++ 및 Java가 여기에서 인기 있는 선택임)로 시작한 다음 원하는 지점에 도달할 때까지 기능을 제거하기 시작했음을 의미합니다. 그리고 일부 사람들에게는 믿기 어려울 수 있지만 언어는 그렇게 설계되지 않았습니다.

우리는 유한한 복잡성 예산을 가지고 있습니다. 우리가 하는 모든 일은 다음에 하는 모든 일을 0.1% 느리게 만듭니다. 기능을 요청하면 다른 모든 기능이 조금 더 어려워지고, 조금 느려지고, 가능성이 조금 낮아질 것을 요청하는 것입니다. Java에 포함되어 있거나 C#에 포함되어 있거나 몇 줄의 코드에 불과하거나 명령줄 스위치를 추가할 수 있기 때문에 여기에는 아무 것도 들어가지 않습니다. 기능은 자신과 미래에 대한 전체 부담에 대한 비용을 지불해야 합니다.

여기서 무엇이 우리의 마음을 바꾸겠습니까? 최종 키워드가 누락되어 정상적으로 작동하지 않는 코드의 예를 보여 주는 사람들.

여기서 키워드가 해결하려고 시도하는 시나리오는 누군가가 실수로 클래스에서 상속하는 시나리오입니다. 어떻게 실수로 클래스에서 상속합니까? 하기 쉬운 실수가 아닙니다. JavaScript 클래스는 본질적으로 취약하므로 모든 하위 클래스가 기본 클래스의 동작 요구 사항을 이해해야 합니다. 이는 일종의 문서 작성을 의미하며 해당 문서의 첫 번째 줄은 단순히 "이 클래스를 하위 클래스화하지 마십시오"일 수 있습니다. 또는 런타임 검사가 있을 수 있습니다. 또는 클래스 생성자를 팩토리 메소드 뒤에 숨길 수 있습니다. 또는 다른 수의 옵션.

즉, JavaScript에서 클래스를 상속하는 유일한 올바른 프로세스는 항상 해당 클래스의 문서를 읽는 것으로 시작됩니다. 기본 클래스가 단순히 코딩을 파생하고 시작해야 하는 제약 조건이 너무 많습니다. 첫 번째 단계에서 시도하지 말아야 한다는 사실을 이미 알고 있어야 하는 경우 3단계에서 제공하는 정적 강제 적용은 어떤 가치를 제공합니까?

처음부터 거기에 가지 말라고 말하는 최소한 두 개의 개별 장애물에 직면했어야 하는 상황이 이미 상황인데 TypeScript에 이 키워드가 있어야 하는 이유는 무엇입니까?

나는 거의 영원히 프로그래밍을 해왔고 나는 그것이 봉인되었고 시도하지 말았어야 했다는 것을 알기 위해 무언가를 서브클래싱하려고 시도한 적이 없습니다. 내가 슈퍼 천재라서가 아니야! 매우 드문 실수이며 JavaScript에서 이러한 상황은 이미 기본 클래스에 대해 먼저 질문해야 하는 상황입니다. 그렇다면 어떤 문제가 해결되고 있습니까?

Typescript의 주요 기능을 강화하는 데 관심이 없다면 기술 뉴스가 Twitter에서 전달할 수 있도록 크게 말해 주세요.

우리는 언어를 디자인하는 방법에 대해 매우 명시적입니다. https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals ; 비목표 번호 1은 이 제안에 정확히 말합니다.

여기에 있는 많은 댓글을 읽은 후의 개인적인 반응은 다른 언어에 존재하는 구성으로 인해 강력한 편향 효과가 있다는 것입니다. 백지 상태의 관점에서 접근하면 상상할 수 있는 수십 가지 동작이 있으며 그 중 TypeScript에는 작은 하위 집합만 있습니다.

메서드에 적용되고 파생된 메서드가 super https://github.com/Microsoft/TypeScript/issues/21388 을 통해 호출한 키워드를 쉽게 상상할 수 있습니다. C#과 Java에 이 키워드가 있다면 사람들은 이 키워드가 맞는 곳에 절대적으로 적용할 것입니다. 사실, 런타임 검사를 적용하는 것이 불가능하고 "파생 클래스가 존재하지 않을 수 있음"보다 기본 파생 계약의 훨씬 더 미묘한 측면이기 때문에 틀림없이 final보다 훨씬 더 일반적으로 시행될 것입니다. final이 아닌 다양한 방식으로 유용할 것입니다. 나는 이 키워드보다 그 키워드를 훨씬 더 선호합니다(복잡성 대 가치 기준을 충족하지 못한다고 생각하지만).

그렇다면 이것을 구현하는 것을 고려하는 적절한 이유는 무엇입니까?

피드백을 볼 때 강력한 고려 사항은 다음과 같습니다.

이 JavaScript 라이브러리의 동작을 적절하게 표현할 수 없습니다.
내 코드가 컴파일되었지만 이 (미묘한) 오류가 있기 때문에 실제로는 없어야 합니다.
이 코드의 의도는 유형 시스템에서 적절하게 전달되지 않습니다.
final은 이것들을 적중하지만 "이 함수는 연속으로 두 번 호출될 수 없습니다" 또는 "이 클래스의 생성은 다음 비동기 틱까지 실제로 완료되지 않습니다"라는 수정자도 마찬가지입니다. 상상할 수 있는 모든 것이 존재해서는 안 됩니다.

"실제로 하위 분류할 수 없는 클래스에서 상속하려고 했기 때문에 디버깅에 몇 시간을 소비했습니다"와 같은 피드백을 본 적이 없습니다. 누군가는 실제로 상상할 수 없기 때문에 '와트'를 올바르게 트리거할 것이라고 말했습니다. 수정자가 존재하더라도 실제로 상황에 도움이 되지 않습니다. 라이브러리가 클래스가 최종적인 것인지 문서화하지 않기 때문입니다(예: fs.FSwatcher https://nodejs.org/api/fs.html#fs_class_fs_fswatcher final) ? 노드 작성자도 모르는 것 같습니다. 따라서 작성자가 최종적이라는 것을 알고 있으면 final이면 충분하지만, 이에 관계없이 문서화될 것이고, final이 없다는 것은 실제로 아무 것도 알려주지 않습니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하거나 GitHub https://github.com/Microsoft/TypeScript/issues/8306#issuecomment-458268725 또는 스레드 https://github.com/notifications/unsubscribe-auth/AA3NA4o9wu54CcJyK1C8WHVjXIQwfmsA8ks를 음소거합니다.

네, 지금 논의가 너무 흩어져 있습니다. IntelliJ/webstorm 문제에 사용되는 것과 같이 투표할 수 있는 추적기에서 이러한 문제를 보고 싶습니다. 얼마나 많은 사람들이 클래스 및/또는 메소드에 대해 final 를 보고 싶어하는지에 대한 실제 수치를 얻으십시오.

마지막은 매우 도움이 될 것입니다

추상 키워드는 프로그래머에게 필드를 재정의해야 함을 상기시키는 데 사용됩니다. 재정의하지 않도록 상기시키는 키워드도 비슷한 방식으로 도움이 될 것입니다.

최종 방법은 코드를 보다 구조화 및/또는 안전하게 만드는 데 중요할 수 있습니다.

예를 들어 타사 플러그인을 지원하는 응용 프로그램이 있다고 가정해 보겠습니다. 모든 플러그인이 생성해야 하는 모든 메서드에 대한 인터페이스를 구현하는 추상 클래스를 확장하도록 강제할 수 있으며 작업 순서를 제어하고 작업 간에 후크를 구현할 수 있도록 하는 몇 가지 최종 메서드를 포함합니다. 이 때문에 애플리케이션은 개별 플러그인의 세부 사항을 인식할 필요가 없으며 여전히 일부 내부 상태를 인식할 수 있습니다.

최종 방법이 없으면 작업 순서를 제어하는 ​​기능을 방해할 수 있습니다. 잠재적으로 응용 프로그램 내에서 버그, 악용 또는 기타 예기치 않은 동작을 일으킬 수 있습니다. 대부분의 상황에는 일종의 해결 방법이 있지만 이러한 해결 방법은 복잡하고 반복적이며 때로는 신뢰할 수 없습니다. 반면 final 메소드는 메소드가 정의될 ​​때 하나의 간단한 솔루션이 됩니다.

또한 이 예제는 플러그인에만 해당되지만 다른 상황에도 적용할 수 있습니다. (팀의 새로운 개발자, 특정 논리가 범위를 벗어나지 않도록 보장, 코드 실행 방법 표준화, 보안 기반 방법이 변경되지 않도록 하는 등 모든 것이 이점을 누릴 수 있음)

@RyanCavanaugh 최종을 원하는 render()에 대한 좋은 예가 있지만 아무도 개방형 원칙에 대해 언급하지 않았습니다(현재 SOLID의 일부로 2위를 차지함).
다른 사람들이 사용할 프레임워크를 작성하는 데 유용할 것입니다.
그렇지 않다면 Typescript에서 개방형 접근 방식을 취하는 데 선호되는 접근 방식은 무엇입니까?

나는 메서드에 final 를 사용하는 것을 좋아할 것입니다(일반적으로 속성과 선언을 가정합니다). 그것은 실제 문제를 일으키고 있습니다. 사람들은 실수로 그 밑에 하나가 있다는 것을 깨닫지 못하고 실수로 계속 무시합니다... 물건을 부수고...

나는 또한 final 메소드 가 큰 가치가 있을 것이라고 생각하며, 다른 사람들이 지적했듯이 반대하는 모든 주장은 final 클래스에 초점을 맞춘 것 같습니다. 별도의 이슈(#9264)가 있었지만 이 이슈가 그것을 다루고 있기 때문에 폐쇄되었지만 실제로는 그렇지 않다고 생각합니다. 해당 문제를 다시 열거나 여기에서 적절하게 해결할 수 있습니까?

내 상황은 추상적인 메서드의 "내부" 버전이 있는 @0815fox 와 비슷하지만 메서드의 "원본" 버전이 중요한 동작을 포함하고 있고 원하지 않기 때문에 절대 재정의하지 않기를 원합니다. 그 하위 클래스를 재정의할 수 있습니다.

이 기능에 찬성하는 커뮤니티의 압도적인 지지에도 불구하고 TypeScript 개발자가 여전히 거부하고 있다는 사실이 당혹스럽습니다...

아마도 중지 간격은 누군가가 특정 클래스를 상속하거나 특정 메서드를 재정의하지 않도록 조언되는 TS-Doc에 표준을 추가하는 것입니다. @final 주석 또는 이와 유사한 것과 같습니다.

글쎄, "최종"에 투표한 다른 모든 사람들이 말한 것에 무엇을 더해야 할까요... 여기 제 투표가 있습니다.

동의. 물론 readonly 를 함수 유형의 속성처럼 취급할 경우 메서드와 함께 사용할 수 있지만 이 해결 방법은 매우 혼란스러울 수 있습니다. 이 문제에 대한 기본 솔루션이 있으면 좋을 것입니다.

final , 특히 final method 는 템플릿 패턴이나 다른 디자인 패턴에서 호출되는 메서드의 순서를 보장하는 메서드의 워크플로를 종종 제어하기 때문에 형식 검사에서 중요하다고 생각합니다.

final 은(는) 가야 할 길입니다.

갱 -이 티켓은 (a)는 폐쇄하고, (나) 나는 새로운 티켓이 마지막 방법에만 초점을 만들하기로 결정 "마지막 방법"토론에 대한 오해의 소지가 제목이 때문이다. 바라건대 그것은 무시하기가 더 어려워지고 약간의 진전을 촉진할 수도 있습니다. 오 예 참조 https://github.com/microsoft/TypeScript/issues/33446

@RyanCavanaugh

복잡성 대 가치 막대

final 대해 무엇이 그렇게 복잡한지 자세히 설명해 주시겠습니까? 특히 abstract 와 같은 키워드가 이미 구현되어 있고 많은 논리/코드를 재사용할 수 있다는 점을 고려할 때 구현하기 가장 쉬운 키워드 중 하나인 것 같습니다.

@vinayluzrao

임의의 예로서, 현재 우리는 구성 서명이 있는 모든 것에서 상속할 수 있다고 말합니다.

// OK
declare const SomeParent: new() => { a: string };
class A extends SomeParent { }

분명히 final 클래스는 new .

function make<T>(ctor: new() => T) {
  return ctor;
}
final class Done {
}
// No problem
const d = make(Done); // d: Done

그러나 이제 모순이 있습니다. 우리는 new 하지만 extends 절에 넣는 것은 합법적이지 않습니다. 따라서 한 수준의 간접 참조가 final .

function subvertFinal(ctor: new() => any) {
  class Mwhahaah extends ctor {
    constructor() {
      super();
      console.log("I extended a final class! So much for 'types'!")
    }
  }
}
final class Done {
}
subvertFinal(Done);

이것은 이미 사람들이 abstract 에 대해 사람들을 놀라게 하고 사람들은 abstract 클래스에 유형 검사 목적으로 존재하지만 실제로는 호출할 수 없는 암시적 구성 서명이 있어야 한다고 끊임없이 주장하고 있습니다.

참고로 이러한 논의에서 "복잡성"이라고 하는 경우의 90%는 TypeScript 사용자가 경험하는 개념적 복잡성을 의미하며 제품 개발자인 당사 측의 구현 복잡성이 아닙니다. 후자는 처리할 수 있는 것입니다(예: 조건부 유형 및 매핑된 유형은 구현 관점에서 매우 복잡합니다). 개념적 복잡성은 제품에 더 똑똑한 엔지니어를 투입하여 처리할 수 있는 것이 아닙니다. 예상치 못한 행동이나 설명하기 어려운 행동을 유발하는 언어를 언어에 추가할 때마다 모든 언어 사용자에게 정신적 부담이 됩니다.

상대적으로 정기적으로 누군가가 아래의 메소드를 (모르는) 재정의하므로 내 코드가 실행되지 않고 상황이 매우 이상한 방식으로 중단되고 사람들이 이유를 모르기 때문에 메소드에 대한 final이 필요합니다. 디버깅하는 데 시간이 오래 걸리는 경우가 많습니다.

@RyanCavanaugh 정말 명확하게 해 주셔서 감사합니다. 하지만 한 가지 생각을 하고 싶습니다. new 와 extends 사이의 강력한 결합으로 인해 귀하가 제시한 예제의 문제가 발생하는 것 같습니다. 아마도 그것이 더 큰 문제일 것입니다. , final 자체가 아닙니다. 왜 이 결합 결정을 내렸는지, 그리고 이 시점에서 취소하는 것이 얼마나 어려운지(취소해야 한다는 의미가 전혀 없는지) 궁금합니다.

그러나 이것이 여기에서 논의하기에는 너무 관련성이 높은 논의인지는 잘 모르겠습니다.

이것은 내가 만난 문제입니다. 이러한 단순 코드 샘플은 컴파일할 수 없습니다.
final 키워드로 완벽하게 해결:

abstract class Parent {
    public abstract method(): this;
}

class Child extends Parent {
    public method(): this {
        return new Child();
    }
}

'Child' 유형은 'this' 유형에 할당할 수 없습니다.
'Child'는 'this' 유형의 제약 조건에 할당할 수 있지만 'this'는 제약 조건 'Child'의 다른 하위 유형으로 인스턴스화할 수 있습니다.

운동장

이거 다시 열 수 있을까요? 이 기능이 필요한 것은 분명합니다

우리는 여러 회의에서 이 문제에 대해 십여 차례 논의했고 매번 반대 결정을 내렸습니다. 열세 번째 토론을 위해 이것을 다시 여는 것은 우리 시간을 잘 활용하지 못합니다.

TypeScript 팀의 결정에 동의하지 않을 수는 있지만 괜찮습니다. 하지만 사람들이 동의하지 않는 결정을 다시, 다시, 다시, 다시 결정하면서 하루 종일 서클을 돌아다닐 수는 없습니다. 이 리포지토리에는 이 제안이 다시 제기되기 전에 초기에 고려할 가치가 있는 수천 개의 다른 제안이 있습니다.

@nicky1038님 의 댓글과 같은 건설적인 토론은 여기에서 매우 환영합니다. 우리가 잠글 필요가 없도록 사람들이 뉴스/재검토 요청에 대해 이 스레드를 계속 핑하지 않도록 요청합니다.

나는 메소드에 대한 final 추가를 지원하기 위해 여기에 있습니다. 하위 클래스가 재정의할 수 없도록 하는 _init_이라는 함수가 있는 기본 클래스가 있습니다. Final은 완벽한 솔루션이 될 것입니다.

또한 메서드에 final 키워드를 추가하는 것을 지원합니다.
요즘은 객체 지향 프로그래밍의 표준입니다.

final 하는 것이 합리적입니다. 특히 다른 사람이 사용할 라이브러리/프레임워크를 구축할 때 함수를 재정의하는 위험조차 허용하지 않으려는 경우에 그렇습니다.

실수가 아니라면 final 추가하면 MyClass final 를 만들 수 있으므로 제네릭으로 작업할 때 'myObj' is assignable to the constraint of type 'T', but 'T' could be instantiated with a different subtype of constraint 'MyClass' 오류로 인한 번거로움을 피할 수 있습니다. 다른 하위 유형이 아닙니다.
100% 확실하지는 않지만 Java에서 이 문제를 해결할 수 있는 방법이라고 생각합니다.

우리는 같은 것을 가지고 있습니다. 많은 다른 패키지가 기본으로 확장할 수 있거나 확장해야 하는 각도로 기본 구성 요소를 만들고 있습니다.
기본 클래스만 구현해야 하는 ngOnChanges 또는 ngOnInit와 같은 것이 있고 하위 클래스는 이를 재정의해서는 안 되지만 실제로는 ngOnInitReal(또는 우리가 호출하는 것)을 구현하므로 호출될 때 완전히 제어할 수 있습니다. 무엇으로.
우리는 이것을 통제할 수 없기 때문에 문서화를 통해서만 이것을 할 수 있습니다. 한 구성 요소 제작자가 이것을 읽지 않으면 해당 구성 요소가 손상될 수 있거나 동일한 작업을 수행하기 위해 기본에서 많은 코드를 복사해야 합니다.

따라서 최종 방법 없이는 견고한 API 계약을 체결할 수 없습니다.

누군가 언급했습니까

class Fancy {
    readonly secureFoo = (message: string) => {
        console.log(message);
    }
}

누군가 언급했습니까

class Fancy {
    readonly secureFoo = (message: string) => {
        console.log(message);
    }
}

이 작업을 수행할 수 있지만 몇 가지 차이점이 있습니다. 예를 들어, 클래스의 각 인스턴스에는 모든 사람이 사용하는 함수가 있는 프로토타입과 달리 자체 함수 복사본이 있습니다.