Typescript: 부분 수업

나는 당신이 모듈에 "부분적"을 사용하고 여기에서 제기된 이 문제를 해결하는 데 도움을 준다고 생각합니다.

https://github.com/Microsoft/TypeScript/issues/447

@disshishkov 아마도 확장 방법으로 충분합니다 : #9

어떤 상황에서 이것을 사용하고 싶습니까? 기존 솔루션은 어떻게 부족합니까?

이것은 자동 생성된 파일과 동일한 유형에 기여하는 사용자 편집 파일이 있는 WinForms 유형 편집 시나리오를 지원하기 위해 C#에서 구현되었습니다. 이러한 상황이 JavaScript/TypeScript에 적용되는지 잘 모르겠습니다.

일부 클래스에는 여러 줄 번호가 있을 수 있습니다. 더 나은 읽기를 위해 여러 개의 개별 클래스로 분할하는 것이 도움이 됩니다. 예를 들어 논리(이 논리가 다른 클래스로 이동할 수 없는 경우), 가시성(비공개 및 공개) 및 기타와 같은 다른 유형으로 분할할 수 있습니다. 부분 클래스의 결합에 문제가 있을 수 있는 경우(예: 동일한 메서드/변수 선언과 같은 2개의 부분 클래스) 컴파일러는 오류를 알리고 throw해야 합니다.

이것은 정말 설득력이 없습니다. 클래스가 너무 커서 단일 파일에서 편안하게 편집할 수 없는 경우 크기 때문에 매우 중요한 디자인 냄새가 납니다(예: http://programmers.stackexchange.com/questions/157482의 주석). 다른 유형/논리/가시성/등으로 분할하는 것은 단일 파일 내에서 IDE 또는 조직에서 처리할 수 있는 것입니다.

클래스가 너무 커서 탐색할 수 없는 이유(탐색 도구가 더 좋아야 하기 때문입니까?)와 언어가 클래스를 _분할_ 하는 것보다 _분해_ 지원하는 더 나은 방법이 있다면 논의할 가치가 있습니다.

개인적으로 "부분 클래스"가 존재해야 하지만 함께 병합되는 모듈처럼 작동해야 한다고 생각합니다. Intellisense가 모든 모듈을 볼 수 있지만(당연히), 이를 포함하는 실제 JS는 필요할 때만 로드되는 모듈이 있는 시스템이 있습니다. 필요한 부분만 로드하는 수업에서도 마찬가지라고 생각합니다. 또한 함수를 만들고 클래스를 사용하여 더 확장하고 싶었습니다. 현재는 모듈로만 이 작업을 수행할 수 있습니다.

부분 클래스의 사용 사례는 생성된 프록시 클래스입니다. 예: WebAPI 또는 SignalR 래퍼. 생성된 프록시 클래스를 사용자 정의 로직으로 확장할 수 있다면 정말 좋을 것입니다. 특히 모델에 대한 클래스를 생성할 때 API에서 반환된 모델 클래스에 비즈니스 로직을 직접 연결할 수 있으면 좋을 것입니다.

+1 크반테토레.

사용 사례는 .net과 정확히 동일합니다. 클래스의 일부가 생성되고(이 경우 Avro 스키마에서) 생성된 클래스로 작업하기 위한 추가 도우미 코드를 추가하려고 합니다.

이 제안이 마음에 듭니다. 하나의 단일 파일에 수집할 수 있는 "데이터 계층"을 형성하는 클래스의 속성/속성을 여러 다른 파일로 분할할 수 있는 메서드에서 분리하기 위해 부분 클래스를 갖고 싶습니다. 코드를 한 눈에 더 명확하고 이해하기 쉽게 만들 것입니다.

내 데이터 계층 파일 :

class A {
  x: number;
  y: number;
  z: number;
}

class B extends A {
  value: string;
  flag1: boolean;
  flag2: boolean;
}

클래스 A의 메소드를 포함하는 파일 :

class A {
  constructor(x: number, y: number, z: number) {
    this.x = x;
    this.y = y;
    this.z = z;
  }
  method1(...) { ... }
  ...
  methodN(...) { ... }
}

클래스 B의 메소드를 포함하는 파일 :

class B extends A {
  constructor(x: number, y: number, z: number, value: string) {
    super(x, y, z);
    this.value = value;
    this.flag1 = false;
    this.flag2 = false;
  }
  method1(...) { ... }
  ...
  methodN(...) { ... }
}

나에게서 +1. tt 템플릿을 사용하여 Typescript 클래스를 생성하고 싶지만 템플릿 생성으로 대체되지 않는 별도의 파일에 추가합니다.

+1 이것은 내가 확장해야 하는 자동 생성 클래스에 정말 도움이 될 것입니다.

Partial Class는 정말 좋은데 그것을 가지고 있다는 것은 말이 되지 않습니다. 그것은 당신에게 디자인 문제가 있음을 보여주었습니다. 프로그래밍의 경험상 규칙은 사용하는 언어에 관계없이 단순 바보(KISS)를 유지하는 것입니다. 큰 클래스를 작은 클래스로 나누는 것입니다. 1) 스크립트를 클래스로 분할하고 호출합니다(다른 클래스도 이를 호출할 수 있음). 바퀴를 재발명하는 대신 더 작은 클래스도), 또는 2) 분리 및 추상/인터페이스/상속/가상 등 또는 다형성으로 변환합니다.

모든 것이 들어 있는 차량이 있다고 가정해 보겠습니다. 부분 클래스는 의미가 없으며 대신 이 작업을 수행하는 것이 더 합리적인 경우 여기에 복잡성과 오버헤드를 도입합니다. Engine 클래스, Tranny 클래스, Drivetrain 클래스, Door 클래스 및 Tire 클래스를 별도의 클래스로 만들고 스크립트를 해당 클래스로 이동하여 호출할 때 여전히 Vehicle 클래스 내에서 Vehicle을 정의할 수 있습니다. 긴 스크립트 및 스크립트 복잡성을 줄입니다. Door 클래스로 단순화할 수 있는 Door 스크립트가 여기 저기에 있다는 것을 알게 될 것입니다. Interface/Abstract/Inheritance/Virtual은 Vehicle 클래스의 일부 스크립트에서 Door 클래스 정의를 변경하는 데 사용할 수 있습니다.

또한 이런 식으로 개발 시간이 줄어들 가능성이 더 큽니다. 한 번 부분 클래스를 많이 사용하는 ASP.NET C# 블로그가 있었습니다. 부분 클래스가 너무 많아서 여기에서 어려움을 겪었고 어디에 있는지 모릅니다. 프로그래밍에서 GOTO 논리를 다루는 것과 같습니다. 나쁜 나쁜!! 버그 수정에 대한 패치를 성공적으로 만들 수 없었고 스크립트가 부분 클래스 더미에 너무 묻혀 있었기 때문에 스크립트를 사용자 정의할 수 없었습니다.

그냥 내 마음에서 나온 1 센트 생각으로 말하십시오.

@fletchsod-developer: 일부 상황은 상속에 의해 적절하게 처리되지만 전부는 아닙니다. 그리고 일부 개발자는 부분 클래스를 오용할 수 있지만 전부는 아닙니다. 부분 클래스가 매우 유용하다고 생각하는 상황이 있지만 마음에 들지 않으면 사용할 필요가 없습니다.

@jfrank14 , 위에서 @basarat 이 제안한 대로 #9가 작동하지 않습니까?

// File1.ts
class Dog { 
 ...
}

// File2.ts
extends class Dog {
  woof() { /* ... */ }
}

@NoelAbrahams , 파일의 file1에서 정의에 액세스할 수 있지만 그 반대는 불가능합니까? 포함 순서와 무관한 한 괜찮습니다.

여러분이 TS용 C#으로 부분 클래스를 고려하기를 진심으로 바랍니다... 저에게 유일한 이유는 코드 생성입니다. 이것이 C#의 부분 클래스 뒤에 있는 주된 이유입니다... 우리는 현재 많은 TS 코드 생성을 수행하고 있으며, 점점 더 많은 일을 할 것으로 기대합니다... 현재 우리는 "// "에 의존해야 합니다.

+1 - 자동 생성 클래스에 기능을 추가하는 데 사용할 수 있습니다. 내가 생각할 수 있거나 현재까지 읽은 다른 우아한 솔루션은 없습니다...

+1 - 코드 생성 클래스. 클라이언트에 직렬화된 C#/Java 객체

생성된 클래스를 병합할 때도 필요합니다!

이것은 생성된 코드와 생성되지 않은 코드를 간단히 병합할 수 있는 매우 유용한 기능입니다.

+1

+1 - 부분적으로 생성된 클래스에도 필요하며 이 목적에 필요하지 않은 상당한 양의 코드를 방출하는 상속보다 더 우아합니다.

+1

이 제한에 다시 부딪쳤습니다. 이 기능을 추가하세요! :+1:

+1

+1

+1

+1

사람들이 무작위로 +1하면 계속 진행되지 않습니다.

지금까지의 사용 사례는 다음과 같습니다.

• 여러 파일에 걸쳐 있는 정말 큰 클래스가 있습니다. @RyanCavanaugh 는 구현의 복잡성을 보증할 만큼 복잡하고 충분하지 않은 코드의 주요 설계 문제일 가능성이 있다고 지적했습니다.
• 그것은 그들을 좋아합니다.
• 다른 주장은 C#에 있는 것 같습니다.
• 다른 인수는 다른 언어에서 생성된 코드에 관한 것입니다.

두 번째와 세 번째 사용 사례는 설득력이 없고 네 번째는 #9를 제공하는 것이 어떻게 매우 유사한 요구 사항과 데코레이터(#2249)를 충족하지 못하는지에 대한 설명이 어느 정도 필요하다고 생각합니다.

#9가 동일한 작업을 수행하고 훨씬 더 일반적일 것 같습니다(자신의 클래스가 아닌 다른 클래스를 확장할 수 있기 때문에). 그러나 두 개의 파일에 클래스 내용이 있고(하나는 손으로 작성하고 다른 하나는 템플릿으로 생성하기 때문에) 두 파일 모두 클래스의 필수 구성원을 동일한 중요성으로 정의하고 그 중 하나를 요구하지 않는다고 말하는 것이 합리적일 수 있습니다. 파일 "확장" 클래스 정의 다른.

거의 실존적인 차이지만 어떤 상황에서는 일부 사람들에게 중요할 수 있습니다.

명시된 이유로 클래스에서 부분적인 것을 원하지 않지만 모듈에서는 IMHO가 의미가 있습니다.

https://github.com/Microsoft/TypeScript/issues/447

부분 클래스는 사용 사례를 전문화하는 데 매우 유용합니다. 이것은 OOP 패턴에 대한 위반이 아니라 다음을 제공하는 코드 문서를 정렬하는 방법입니다.

1. 여러 파일에서 클래스/유형 정의를 분할하는 기능. 대용량 코드 파일의 경우 유지보수성++ 기능입니다.
2. 컴파일러/빌드 시스템이 컴파일 타임에 조건부 연결을 사용할 수 있는 기회. 유추 MSBuild, C#의 구체적인 사용 사례: DBML, 디자이너 클래스 및 https://github.com/dotnet/corefx/pull/2045/files 와 같은 더 멋진 것들
3. 고유한 보호 기능으로 두 개(또는 그 이상)의 개발자가 코드 체크인 중에 서로 충돌하지 않습니다. 갈등 해결이 터진다! :)
4. 기본 partial 클래스에 코드를 생성한 다음 사용자 지정 오버로드에 대해 다른 부분을 생성할 수 있습니다. 완벽하게 작동합니다!

저는 비즈니스 로직과 데이터 레이어를 별도의 클래스로 분리하는 것을 믿으며 주로 이러한 레이어에서 정적 메서드를 사용합니다. 나는 그것이 더 많은 코드와 덜 유지 보수가 될 수 있다는 것을 정말로 알지 못합니다.

확장 메서드는 객체지향 패턴의 영향을 받는 핵심 언어 기능으로 컴파일 시 처리되지만 부분 클래스는 컴파일 전 단계에서 스티칭되는 문서/코드 레이아웃을 처리합니다. 부분 클래스, 추상 클래스 및 확장 메서드의 유사성에도 불구하고 분명한 차이점이 있습니다.

:+1: 무해한 "부분 클래스"를 TypeScript로 가져오기 위한 것입니다.

부분 클래스에 대한 나의 사용 사례는 코드 생성을 위한 것입니다. 우리 팀은 한 파일에서 클래스의 일부를 자동 생성하고 다른 파일에서 직접 사용자 지정 메서드와 속성을 추가할 수 있어야 합니다. 이 사용 사례가 선택한 언어와 관련이 없기 때문에 @RyanCavanaugh 가 "그런 종류의 상황이 JavaScript/TypeScript에 적용되는지 확실하지 않은" 이유가 약간 혼란스럽습니다.

데코레이터도 확장 메서드도 부분 클래스만큼 우아하게 코드 생성 문제를 해결하지 않으며 각각은 상당한 추가 복잡성을 가지고 있습니다.

+1

+1

코드 생성 목적으로 +1.

C# 환경에서 C# 클래스의 변환기를 TypeScript 클래스에 통합하면 TypeScript 클래스라고도 하는 클라이언트 측이 자동으로 생성되고 partial 클래스가 생성되므로 서버와 클라이언트 측 간에 클래스에 대한 두 가지 다른 정의를 유지할 필요가 없습니다. 이 문제가 요청하는 것은 기본 TypeScript에서 계속 개발하면서 필요할 때 사용자 정의를 허용할 것입니다.

코드 생성 시나리오의 경우 +1

+1 코드 생성에 매우 유용

코드 생성에 상속을 사용하지 않는 이유는 무엇입니까?

상속은 더 복잡하고 더 많은 오버헤드가 있습니다.

2015년 8월 10일 월요일 오전 10시 9분 Gorgi Kosev [email protected]이 다음과 같이 썼습니다.

코드 생성에 상속을 사용하지 않는 이유는 무엇입니까?

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/Microsoft/TypeScript/issues/563#issuecomment -129468291
.

상속은 쓸모없는 이름 커플링을 만듭니다.

상속은 다음과 같은 이유로 덜 훌륭합니다.

1. 프로토타입 체인을 불필요하게 심화시키고 인스턴스화 속도를 늦춥니다.
   대부분의 앱에서 큰 문제는 아니지만 게임을 제외한 모든 것이 가능합니다.
2. 추상 및 재정의가 없으면 일부 유형 안전성을 잃거나
   둘 사이의 캐스팅과 같은 일부 수상한 패턴의 필요성을 소개합니다.
   유형;
3. 기본 클래스가 다음과 같은 아이디어를 전달하므로 전반적으로 혼란스럽습니다.
   codegen의 경우는 드물게 다른 클래스에 의해 확장될 수 있습니다.

typescript에 codegen을 지원하는 부분 클래스가 있다고 말하지 않고
부분 클래스가 상속이나
구성.

@JoshMcCullough JS의 상속 오버헤드는 최소화되며 부분 클래스보다 얼마나 지저분한지 모르겠습니다. 클래스를 사용하면 잠재적으로 클래스를 10개의 파일로 분할하고 모든 곳에서 메서드를 추적할 수 있습니다.

@yahiko00 여기서 말하는 "쓸모없는 이름 커플링"이란? 아래 2번(확장 클래스의 이름을 하드코딩)을 얻기 위해 해야 할 일을 언급합니까?

@hdachev

1. 약간의 오버헤드가 있지만 아주 미미 합니다. 몇 가지 기계 명령으로 직접 변환되는 작업을 수행하는 경우에만 눈에 띕니다.
2. 좋은 점 - 생성된 다른 클래스에서 생성된 클래스를 참조해야 할 때 확장된 클래스를 얻지 못합니다.
3. 이러한 클래스는 실제로 확장을 의미합니다. 그렇지 않으면 클래스를 생성하고 끝낼 수 있습니다. 그렇죠?

AFAIK 이것은 ES7+ 레이더에 있지 않습니까? 그게 문제일수도...

어쨌든 기존 클래스의 프로토타입에 추가 항목을 추가하는 것은 JavaScript에서 매우 간단하고 전혀 드문 일이 아니므로 이에 대한 구문을 갖는 것이 좋습니다...

TS에서는 간단하지만 배후에서 JS는 두 배가됩니다.
생성된 모든 데이터에 기본 클래스를 사용하는 경우 "프로토타이핑"
사물. 당신이 많은 것을 가지고 있지 않다면 아마도 심각한 성능 영향은 없을 것입니다.
데이터 개체이지만 "부분적
수업"이 가능합니다.

2015년 8월 10일 월요일 오전 11:03 Gorgi Kosev [email protected]
썼다:

@JoshMcCullough https://github.com/JoshMcCullough 상속 오버헤드
JS에서는 최소한이며 부분 클래스보다 얼마나 지저분한지 알 수 없습니다.
그것들을 사용하면 잠재적으로 클래스를 10개의 파일로 분할하고
곳곳에 있는 방법들.

@yahiko00 https://github.com/yahiko00 무슨 "쓸모없는 이름
커플링"에 대해 이야기하고 있습니까? 필요한 항목을 참조합니까?
아래 2번(확장 클래스의 이름을 하드코딩)을 얻으려면 어떻게 해야 하나요?

클래스 MyClass는 GeneratedMyClass { ... }를 확장합니다.

@hdachev https://github.com/hdachev

1.

약간의 오버헤드가 있지만 최소한의
https://jsperf.com/prototype-chain-vs-direct-calls - 눈에 띄는 것만
몇 대의 기계로 직접 변환하는 작업을 수행하는 경우
지침
2.

좋은 점 - 해야 할 때 확장된 클래스를 얻지 못합니다.
생성된 다른 클래스에서 생성된 클래스를 참조합니다.
삼.

이러한 클래스는 실제로 확장되어야 합니다. 그렇지 않으면
그것들을 생성하고 그것을 끝내십시오. 맞습니까?

AFAIK 이것은 ES7+ 레이더에 있지 않습니까?

어쨌든 기존 클래스의 프로토타입에 추가 항목을 추가
JavaScript에서는 매우 사소하고 전혀 드문 일이 아니므로
그것에 대한 구문을 갖는 좋은 생각 ...

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/Microsoft/TypeScript/issues/563#issuecomment -129483174
.

@Davidhanson90 그 파일에는 클래스가 없습니다. 다른 스레드에 이것을 게시하려고 했습니까?

올바른 스레드에 게시하겠습니다. https://github.com/Microsoft/TypeScript/issues/447

+1

+1

+100

+1

+1

코드 생성을 위해 +1.
저는 angularjs와 webapi에 빠져 들었고 본질적으로 C# 개체 및 서비스에서 자동 JS 정의를 생성하는 도구를 만들고 싶습니다. 그런 다음 "스캐폴딩된" JS 정의를 편집하지 않고도 이러한 클래스를 확장할 수 있기를 원합니다. 몇몇 다른 사람들이 이것을 요청하는 것을 보았고 우리도 비슷한 사용 사례를 가지고 있는 것 같습니다.

+1 코드 생성

+1 코드 생성, angular에는 많은 상용구 코드가 있습니다. 우리는 이미 많은 생성을 수행하고 있지만 부분 클래스를 사용하면 훨씬 더 많은 작업을 수행할 수 있습니다.

코드 생성을 위해 다시 +1. 다른 파일의 클래스를 확장하는 것은 기껏해야 지저분합니다.

@RyanCavanaugh , 이것을 "+1" 모드에서 벗어나 생산적인 방향으로

-1 다음 구문이 믹스인에 더 좋습니다. #2919

왜 부분 클래스와 믹스인을 둘 다 가질 수 없는지 잘 모르겠습니다. 전혀 관련이 없는 두 가지 기능.

+1

이것은 코드가 생성될 때 유용하지만 생성된 코드에 항목을 추가하기 위해 코드를 수정하고 싶지는 않습니다.

+1

다음 두 가지 사용 사례를 모두 충족해야 하는 제안이 있습니다.

1. 당신은 다른 장소에서 당신 자신의 클래스의 메소드를 작성하기를 원합니다.
2. 다른 사람의 클래스에 새 메소드를 추가하려고 합니다(예: 내장).

(2)의 경우 일반적으로 :: 연산자를 사용하여 중위 구문을 얻습니다.

그러나 이전 클래스를 새 인터페이스의 일부로 사용하거나 동적으로 전달하려면 프로토타입을 실제로 수정해야 합니다.

interface ITimes {
    times(n: number): number
}

Array implements ITimes {
    times(n: number): number {
        return this.length * n
    }
}

// The compiler should check that all methods of ITimes and IOther are implemented.
Number implements ITimes, IOther {
    times(n: number): number {
        return this * n
    }

    other(): void {}
}

// The old types should typecheck with the new interface.
const x: ITimes = true ? [] : 0
x.times(3)

// The interface list can be empty. This essentially gives you partial classes.
MyClass implements {
    anotherMethod(): void {}
}

(예제에서는 문자열 메서드 이름을 사용하지만 이것들은 기본 제공 유형이므로 유형 검사가 가능하면 기호를 사용하는 것이 더 좋습니다.)

이것이 진정한 부분 클래스에 비해 개선된 점은 클래스에 단일 정의가 있고 다른 곳에서는 이를 확장한다는 것입니다. 이것은 클래스를 가져올 명확한 장소가 있고 JS로의 번역을 더 쉽게 만든다는 것을 의미합니다.

:+1: 부분 수업도 보고 싶습니다.

이 기능의 상태는 무엇입니까?

이 사용 사례는 다음과 같습니다.

Set#add , 'Set#remove' 메소드를 사용하여 Set 클래스를 정의하는 Math 패키지가 있습니다.

// math.ts
export partial class Set {
  add(){}
  remove(){}
}

Relation 및 Tuple 클래스를 정의하는 선택적 , heavy , Relational 패키지가 있습니다.

이 Relational 패키지는 Set#product 메서드도 추가합니다.

// relational.ts
///<reference path="./../math/tsd.d.ts"/>
partial class Set {
  product(){}
}

export class Relation(){}
export class Tuple(){}

부분 수업을 통해 보다 유연한 방식으로 수업을 구성할 수 있습니다. 무거운 relational 패키지를 사용하지 않으려면 기본 설정 기능을 계속 사용할 수 있습니다. 다른 partial 클래스는 클래스에 추가 기능만 추가됩니다.

나는 이 경우에 부분을 사용하지 않고 멋진 API를 가질 무언가를 하기 위해 머리를 긁적입니다.

내가 가져올 수 있는 것은 저장소 패턴뿐입니다.

// Without partials

// base

export class Base {
    static registerOperation(opName, method){
        this.prototype[opName] = method;
    }
    operation(name, ...args){
        return this[name].apply(this, args);
    }
}

// math.ts
import {Base} from './base';
class Set extends Base{
    // Define the methods here
    add(){}
    remove(){}
}

// Or here
Set.registerOperation("add", function(...){});
Set.registerOperation("remove", function(...){});

// relational.ts
import {Set} from './../math/math';

Set.registerOperation("product", function(...){});

// app.ts

import {Set} from 'math';

var set = new Set();
set.add // compiler error
set.remove // compiler error
set.product // compiler error

// have to use something like
set.operation("add", args);
// or
(<any>set).add(arg);

+1 WebApi를 통해 클래스와 프록시를 생성하기 위해 t4를 사용하고 있습니다. 자동 생성은 타이프스크립트에서 많이 사용되는 것 같은데 자동 생성에 관해서는 부분 클래스가 필요합니다!

특히 React에서 동일한 클래스의 측면을 분할하는 데 좋습니다.
+1

+1 코드 생성 및 "적절한 분리"는 클래스에 정의하는 것이 좋지만 별도의 소스 코드에서 유지 관리되는 유효성 검사와 같은 클라이언트별 속성이 있는 순수 재사용 가능한 데이터 개체의 경우입니다.

부분 클래스의 코드 생성 및 이러한 클래스에 대한 추가 멤버를 별도의 파일로 핸드코딩하려면 +1입니다.

+1

+1 js api 서비스에 메소드 기반이 넓습니다. 각 메소드를 이해하기 쉽게 파일로 분할하는 것이 가장 좋습니다.

fb (facebook) 또는 gq (google analytics) 와 같은 api 서비스는 개발 내내 사용할 수 있는 하나의 전역 클래스 또는 개체가 제공됩니다.

+1

이 기능은 우리에게도 큰 장점이 될 것입니다.

우리는 모든 유형의 클라이언트가 이를 통해 서버에 연결하고 통신할 수 있는 미들웨어를 개발했습니다.

우리는 서버에 의해 노출된 것을 기반으로 클라이언트 코드의 일부를 생성합니다.

지금까지는 모든 것이 정상이었습니다. 그러나 이제 우리는 이기종 개체 컬렉션을 전송할 수 있기를 원합니다(그러나 동일한 기본 클래스로). 전송된 개체는 서버 API를 기반으로 생성된 코드의 일부입니다.

상속의 힘을 사용하려면 추상 메서드가 이 경우 핵심입니다. 그러나 우리 개발자들은 생성된 코드에 메소드를 추가하지 않을 것입니다. 저는 모두가 그 이유를 알고 있다고 가정합니다 ;)

내가 이해하는 한(저는 C# 개발자입니다) 여기에 제안된 솔루션(https://github.com/Microsoft/TypeScript/issues/9)으로는 그렇게 할 수 없습니다.

따라서 부분 수업은 우리에게 완벽할 것입니다. 우리는 클래스를 부분적으로 생성하고 개발자가 논리나 메서드를 추가해야 하는 경우 원하는 위치에 다른 부분을 작성하기만 하면 됩니다.

+1

+1 코드 생성에 매우 유용

모듈 증대가 기본적으로 특정 기능으로서 이에 대한 필요성을 무효화하는지 궁금합니다.

생성된 클래스가 있으면 다음과 같은 작업을 수행할 수 있어야 합니다.

import {MyClass} from "./MyClass.generated"

MyClass.prototype.partialMethod1 = function() {
  return true;
}
MyClass.prototype.partialMethod2 = function(abc: string) {
  this.doSomething(abc);
}

declare module './MyClass.generated' {
  interface MyClass {
    partialMethod1(): boolean;
    partialMethod2(abc: string): void;
  }
}

@disshishkov 커버 아래에서 구현하는 좋은 방법처럼 보이지만 수동으로 프로토타입을 수정하고 해당 인터페이스를 유지 관리할 필요 없이 언어에서 적절한 일급 지원을 원합니다.

나는 Elephant-Vssel에 동의합니다. 부분 클래스의 수동으로 제작된 부분은 생성된 부분에서 가능한 한 느슨하게 결합되어야 합니다(TS의 디자인 타임에).

@david-driscoll의 제안은 많은 경우에 효과가 있습니다. 그러나 내가 말할 수 있는 한 프로토타입은 내부 변수에 액세스할 수 없습니다. 이는 클래스의 핵심 부분을 생성한 다음 사용자 지정 코드로 보강하려는 코드 생성 컨텍스트에서 이 접근 방식의 유용성을 제한합니다.

+1

@david-driscoll은 이 기능을 제거하는 훌륭한 방법으로 보입니다. (개인/보호된 속성에 대한 액세스 기능을 추가해야 함). 다중 부분 클래스 선언은 어떻게 되는지 궁금하십니까? 이들의 상호 가시성은 무엇입니까?

++ 1 자동 생성 모델을 확장하려고 할 때 부분적 부족은 정말 나를 아프게 합니다..

여기 범위의 유일한 것은 기본적으로 @david-driscoll이 제안한 것입니다. 새 메서드(프로토타입에 넣을 것)와 새 _non-initialized_ 속성(codegen이 없음)을 선언할 수 있지만 새 초기화 속성은 선언할 수 없습니다. (이것은 생성자 codegen에 부작용이 있기 때문입니다).

downvoted, 내 프랑스어를 용서하십시오. 부분 클래스는 OOP에서 불가피한 God 클래스를 여러 파일로 청크하여 관리하기 쉽도록 (여전히 God 클래스이지만) 어리석은 시도입니다.

OOP에는 미래가 없습니다.

FP로 오세요, 우리는 쿠키와 단일 클래스 없이 프로그램을 작성하는 방법을 가지고 있습니다.

그래서 우리는 이미 기본적으로 interface A { method(): void } A.prototype.method = function() { }; 통해 이것을 허용합니다. 이것을 정확히 이해하기 위해 설탕으로 코드화하는 것입니다.

자전거 보관소에서 한 가지 키워드는 partial 입니다. 간략한 역사적 비네트: C#에서 partial class 는 원래 extension class (하나의 선언을 제외한 모든 선언에 적용)가 될 예정이었지만 어떤 선언이 어떤 선언이 될지에 대한 명확한 구분이 없었습니다. extension 및 비확장 선언이 될 선언. 대신 _all_ 클래스에 배치해야 하는 수정자 partial 가 있습니다.

이것은 TypeScript의 경우가 _아닙니다_. 오히려 그 반대. 여기서 하나의 클래스("_primary_ 선언"이라고 함)만 생성자/초기화된 멤버 필드를 가질 수 있습니다. 기본 선언에는 새로운 수정자가 없습니다. 다른 모든 선언("_extension_ 선언"이라고 함)에는 정적, 메서드 및 초기화되지 않은 필드만 있을 수 있으며 기본이 아님을 나타내기 위해 일부 수정자가 _필요_합니다.

현재 가장 좋은 추측은

class Foo {
  x = 6; // only legal to initialize here
  constructor() { } // only legal to have constructor here
  someMethod() { }
}

// vvvvvvvvv thoughts?
   extension class Foo {
     someOtherMethod() {
     }
   }

:sparkles: :bike: :집: :sparkles:

Bikeshedding이든 아니든 이것은 미래의 ECMAScript 표준을 방해할 가능성이 있기 때문에 삭제된 #311 처럼 끔찍하게 들립니다. 왜 이것이 고려할만한 가치가 있지만 적절한 mixin 지원은 그렇지 않습니까?

extension 키워드를 사용하면 확장 방법 과 충돌합니까? 아니면 확장 방법을 완전히 무효화합니까?

@kitsonk 믹스인 제안에는 더 많은 열린 질문이 있다고 생각합니다. 부분 클래스 제안은 TypeScript에서 이미 허용되는 일부 구문 설탕과 함께 코드화한 것입니다(이 기능은 문자 그대로 이미 가지고 있는 구문에 대한 구문 재매핑으로 수행될 수 있음).

@Elephant-Vessel 부분 클래스가 발생하면 확장 메서드가 발생하지 않는다고 생각합니다. 클래스는 우리의 제약 조건을 감안할 때 확장 방법이 의미가 있는 유일한 장소이며 제안된 ES7+ 바인드 연산자는 확장과 유사한 구문을 구사할 수 있는 더 나은 방법입니다.

@RyanCavanaugh : 나에게는 한 클래스가 기본이고 다른 클래스가 아닌 것을 요구하는 것이 약간 제한적인 것 같습니다. 한 파일에 클래스의 모든 메서드가 포함되고 다른 파일에는 모든 속성이 포함되도록 코드를 분할하려는 경우 둘 다 더 명백하게 기본적으로 보이지 않으며 왜 선택해야 합니까? 중요도가 모두 같고 컴파일러에 의해 병합되는 부분을 갖는 것이 더 깨끗하지 않습니까?

@RyanCavanaugh ... 나는 C#이 하는 것과 똑같은 방식으로 그것을 할 것입니다 ... 그것은 코드 생성에 훌륭하게 작동합니다 ... 나는 그것이 C #에서 해결해야 할 주요 문제라고 생각합니다 ... 내 기억이 흐릿하지만 ... 문제가 없었고 몇 년 동안 사용되었으며 전투 테스트를 거쳤습니다...

부분/확장 클래스가 초기화된 필드를 가질 수 없는 경우 기본적으로 부분 클래스에 특정한 경량 계약인 C#에서 알고 있는 부분 메서드 와 같은 것을 지원하는 것이 더 깔끔할 것이라고 생각합니다. 그처럼:

public partial class MyGeneratedClass
 {
     partial void Initialize();
     public constructor()
     {
          //...
         this.Initialize();
    }
 }

 public partial class MyGeneratedClass
 {
     partial void Initialize()  { //... }
 }

타사 클래스를 부분화/확장할 수 있어야 하는 필요성은 partial/extends 일반적으로 선택 사항이지만 부분 메서드를 사용하는 데 필수로 만듦으로써 아주 쉽게(?) 해결할 수 있습니다.

이것이 우리가 여기서 원하는 컨셉에 깔끔한 표현력과 조작력을 가져다 줄 수 있다고 생각합니다.

믹스인을 찾으시는 분들

JavaScript가 진행되는 한 믹스인을 우아하고 자연스럽게 관용적으로 올바르게 수행할 수 있는(및 흐름 분석) 제안 을 객체를 고려하십시오.

function enableBeingPositioned<a>(
   // hypothetical syntax
   something: a /* <-- before type */ => a & { x: number; y: number; } /* <-- after type */
): void { 
   something.x = 0;
   something.y = 0;
}
let value = {};
value.x; // <-- should not typecheck
enableBeingPositioned(value);
value.x; // <-- should typecheck

Java와 같은 언어는 부분 클래스/구조체를 제공하지 않습니다. C#의 틈새 기능입니다. C# "부분 클래스/구조체" 개념을 최대한 모방하는 것이 가장 좋은 방법입니다.
사전 컴파일 단계에서 TS 컴파일러가 할 수 있는 첫 번째 일은 메모리의 부분 코드 블록을 스티칭한 다음 일반 컴파일 파이프라인 경로로 이동하는 것입니다. 이것은 TypeScript의 v1.0.0-preview1.0000 부분 클래스 기능을 사용하기에 충분합니다.
C#이 제공하는 것 이외의 것은 기능이 발전하고 평가판/미리보기보다 오래 지속되는 이후 버전에서 도입될 수 있는 것입니다. 모서리 케이스와 비슷한 종류의 애매한 물건은 한 번에 하나씩 별도로 논의할 수 있으며 나중에 적합성 및 마감에 대해 걱정할 수 있습니다. IMO.

또한 부분 및 확장 클래스를 C# 방식으로 정확히 수행하는 데 동의합니다.
구문 및 의미 측면에서 가장 좋은 방법입니까? 둘 다 작동합니까?
각각의 사용 사례에 매우 적합합니다. 부분 수업은 향상
생성된 코드의 유용성 확장 방법은 사용성을 향상시킵니다.
인터페이스, 지정된 제네릭 및 세 번째에서 작동하는 정적 메서드
파티 유형. 둘 다 정말 멋지지만 둘 다 그렇지 않다는 것을 기억하십시오.
위의 제안된 구문 때문에 동일한 기능을 여기에서 말하는 것입니다.

확장 메서드를 사용하면 이 작업을 수행할 수 있습니다(형식 지정 부족,
전화로 입력):

확장 MyType[] {
뭔가 특정ToMyType() { ... }
}

WeirdThirdParty데이터 구조 확장{
같은여기() { ... }
}

밑줄과 같은 라이브러리를 사용할 수 있는 것과 같은 다른 것들 중에서
기본적으로 구문상의 이점을 얻는 것을 의미합니다.
내장 유형을 실제로 오염시키지 않고 확장합니다.

너무 간단합니다 - 둘을 하나의 동일한 것으로 취급하지 마십시오. 둘 다 매우
멋지지만 같은 것은 아닙니다. 나는 개인적으로 둘 다 우리의
언어.

그건 그렇고, 부수적으로 많은 사람들이
코드 생성 및 모든 사람에게 그것이 자리가 없다는 것을 설명할 준비가 되어 있습니다.
자바 스크립트에서 같은 것을 달성하는 더 관용적 인 방법이 있기 때문입니다.
코드 생성이 일부에서 큰 도움이 되는 두 가지 방법이 있습니다.
내가 지금 하고 있는 것과 같은 프로젝트.

• 게임과 같이 성능에 민감한 프로젝트에서
  유용한 작업으로 CPU 예산을 최대화하는 모든 것, codegen은 많은 도움을 줍니다.
  추론하기 쉽고 고도로 최적화 가능한 코드 생성
  / 정말 잘 나가는 모노모픽 코드. 예를 들어,
  엔티티/컴포넌트 게임 엔진, 생성된 코드는 수많은 작업에 도움이 될 수 있습니다.
  구성 요소를 함께 연결하기 위한 매우 빠른 상용구 코드, 이벤트
  파견 등
• 대규모 비즈니스 앱에서 생성된 코드는 최대 마일리지를 얻는 데 도움이 됩니다.
  유형 시스템, 예를 들어 매우 구체적인
  컴파일 시간을 최대화하는 데이터베이스 쿼리 등의 서명
  확인하고 리팩토링을 돕고 디버깅을 크게 단순화합니다.
  매우 간단한 오케스트레이션 코드를 단계별로 실행할 수 있기 때문입니다.
• 큰 문제는 일부 구성 요소를 동기화된 상태로 유지할 때입니다.
  여러 언어 환경(예: 메시징과 관련된 것)
  프로토콜 버퍼 또는 json 메시지 인터페이스 등

어떤 부분이 궁금하신 분들을 위해 또 다른 사이드 노드로
클래스는 생성된 부분을 유지하는 가치인 codegen과 관련이 있습니다.
소스 제어 요구 사항에서 별도의 파일로 클래스를 가져옵니다.
생성된 항목은 일반적으로 빠르게 변화하는 빌드 아티팩트이며
당신의 리포지토리에 커밋되는 것을 원하지 않습니다.

C#이 가지고 있는 것과 마찬가지로 이 개념의 잘 알려져 있고 시도된 모델에 따라 이를 구현하는 아이디어가 마음에 듭니다. '모방'은 부정적인 의미를 내포하고 있지만 지능적으로 수행하면 상당한 가치가 있습니다. 반면에 '지능적인' 부분은 다양한 상황과 제한 사항을 인식하는 것이므로 TypeScript의 부분이 C#의 부분과 정확히 같지 않은 경우 항의하지 않겠습니다.

@Elephant-Vessel, 나는 그것이 C# 부분의 사본이 될 필요가 없다는 데 동의합니다. 일반적인 디자인은 C# 부분에서 최대한의 영감을 얻으면서 TypeScript/JavaScript를 중심으로 먼저 제작될 수 있습니다. 내 제안은 ' partial 키워드 등록' 및 '부분 연결'을 첫 번째 단계로 사용하고 실험적/미리보기 기능으로 제공하는 것입니다(그래서 소비자는 프로덕션 코드에서 이에 의존하기 시작하지 않습니다. 방망이에서). 나중에 커뮤니티 응답을 기반으로 프로덕션 준비 및 RTM이 될 때까지 기능을 발전시킵니다. 모든 종류의 까다로운 문제와 시나리오에 대해 미리 걱정하면 문제가 더 지연될 가능성이 큽니다.

+1 - 생성된 객체를 확장하고 유지합니다.

생성된 코드를 유지하기 위한 +1

polyfill을 만들고 큰 클래스를 나눴습니다.

클래스를 인터페이스로 정의합니다.

export class C {
  constructor() {
  }
}
export interface C {
  m(): void;
}

클래스 멤버를 구현합니다.

export default class extends C {
  m(): void {
  }
}

구현을 병합합니다.

import {C} from './core';
import m from './member/m';

compose(C, m);
export {C}

import {assign} from './assign';
import {concat} from './concat';

export function compose<T extends new (...args: any[]) => any>(target: T, ...sources: T[]): T {
  return concat([target], sources)
    .reduce((b, d) => {
      void assign(b.prototype, d.prototype);
      for (const p in d) if (d.hasOwnProperty(p)) b[p] = d[p];
      return b;
    });
}

https://github.com/falsandtru/spica/commit/a6ff30da5319db5f25f703a29da48fc0f7dbe2fe

나는 이것이 하나의 특정한 이유 때문에 끔찍한 생각이라고 생각합니다. 그것은 전역, 주변, 외부, 이름 공간 및 취약 선언 순서 종속 상속 문제에 대한 이미 복잡한 규칙을 훨씬 더 악화시킬 것입니다. 이것은 C#이 아니며 이름 확인 및 멤버 선언이 매우 다릅니다.

아마도 클래스 대신에 객체나 네임스페이스를 사용하십시오. 정말로 이것을 해야 한다면 모듈 패턴을 드러내는 것입니다. 그렇지 않으면 클래스가 너무 클 수 있습니다.

또한 데코레이터를 사용하여 생성된 코드와 손으로 작성한 코드 간의 연결을 구현할 수 있습니다.

다른 솔루션이 있습니까?

이것도 TS에 추가되면 좋겠네요

코드 생성 목적으로 +1(추가 부분 클래스 정의가 있는 WCF 서비스 참조의 DTO)

코드 생성 목적으로 +1. 내 사용 사례는 다음과 같습니다. render() 함수가 react-templates 를 통해 외부적으로 생성되는 React 구성 요소가 있습니다.

partial 클래스를 사용하면 이러한 함수와 기본 클래스( Component )를 비교하여 유형을 확인할 수 있습니다. 부분 클래스가 없으면 내가 할 수 있는 유일한 일은 함수를 메인 클래스에 바인딩하고 최선을 다하는 것뿐입니다.

다음 TS 2.0에서는 일부 코드 생성 사례가 this 유형 기능으로 처리될 수 있다고 생각했습니다.

예를 들어 앞에서 설명한 경우 대신

partial class MyComponent extends React.Component<any,any> {
    render() {
        ...
    }
}

난 쓸수있다

function render<this extends MyComponent>()
        ...
}
MyComponent.prototype.render = render;

+1 개발자로서 여러 템플릿이 여러 파일에 분산된 동일한 클래스를 생성/수정할 수 있도록 부분 클래스를 원합니다.

내 의견은 특히 믹스인이 아닌 부분 클래스에 관한 것입니다. 둘은 근본적으로 다릅니다. 부분 클래스는 물리적 코드를 분해하는 것이고, 믹스인은 논리적 동작을 재사용 가능한 특성으로 분해하여 유형과 값 수준 모두에서 다른 객체를 풍부하게 하는 것입니다.
나는 부분 클래스가 TypeScript에 좋은 아이디어라고 생각하지 않습니다. 반면에 Mixins는 @aleksey-bykov가 지적한 것처럼 TypeScript의 유형 시스템과 JavaScript 관용구 모두에서 향상된 표현력과 메쉬를 매우 잘 제공하는 좋은 아이디어입니다.

@wendelm 은 ES 모듈이 물리적이라는 점을 감안할 때 이를 수행하는 깨끗한 방법을 생각할 수 있습니까? 부분 클래스는 모듈이 물리적이지 않고 논리적인 C#과 같은 언어에서 잘 작동하며 많은 의미를 갖습니다. CLR의 관점에서 네임스페이스는 존재하지 않습니다. 단지 클래스 이름에 점이 포함될 수 있다는 것뿐입니다(@ahejlsberg와의 인터뷰 출처).

+1 부분 수업이 필요합니다!

인터페이스를 확장할 수 있습니까? 인터페이스에는 Swift와 같이 구현된 기능이 있을 수도 있습니다.

interface Rect {
    x: number
    y: number
}

extension Rect {
    area() => this.x * this.y
}

스위프트 버전:

protocol Rect {
    var x: Float {get}
    var y: Float {get}
}
extension Rect {
    func area() -> Float {
        return self.x * self.y
    }
}

+1

코드 생성과 부분 클래스는 함께 진행됩니다.

상속은 본질적으로 미화되는 #include 지시문에 대한 빈약한 솔루션입니다.

Angular 2를 예로 들어 보겠습니다. 상위 클래스에서 메타데이터 를

@tsvetomir TypeScript 문제가 아닌 Angular 문제입니다.

상속은 본질적으로 미화되는 #include 지시문에 대한 빈약한 솔루션입니다.

예, 상속은 좋지 않은 솔루션이지만 문제는 처음부터 클래스를 사용하는 것입니다. 그들은 자신의 자리가 있지만 매우 제한적입니다. JavaScript 클래스는 다른 언어의 클래스에 비해 매우 약하고 표현력이 부족합니다.

Typescript는 "Angular" 언어가 아닙니다...

2016년 7월 23일 오후 9시 46분에 Aluan Haddad < [email protected] [email protected] >이(가) 다음과 같이 썼습니다.

@tsvet omirhttps://github.com/tsvetomir 이는

상속은 본질적으로 미화되는 #include 지시문에 대한 빈약한 솔루션입니다.

예, 상속은 좋지 않은 솔루션이지만 문제는 처음부터 클래스를 사용하는 것입니다. 그들은 자신의 자리가 있지만 매우 제한적입니다. JavaScript 클래스는 다른 언어의 클래스에 비해 매우 약하고 표현력이 부족합니다.

당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하거나 Gi tHubhttps://github.com/Microsoft/TypeScript/issues/563#issuecomment -234753589에서 확인하거나 읽기를 음소거합니다 .https://github.com/notifications/unsubscribe-auth/AJPCIh7n2_0dt00kw- XJv7tc9LB0tPsIks5qYtH4gaJpZM4CcixK.

어떤 식으로든 Angular와 관련된 문제라고 생각하지 않습니다. 부분 수업이 도움이 되었을 수 있는 특별한 경우입니다.

이 요청은 C#에 대한 과거 경험과 친숙한 기능의 부족에서 비롯됩니다. TypeScript 는 .NET과 거리를 두려고

이 요청은 C#에 대한 과거 경험과 친숙한 기능의 부족에서 비롯됩니다. TypeScript가 .NET과 거리를 두려고 하지 않기 때문에 비교는 불가피합니다. 사용자는 어떤 형태의 기능 패리티를 기대합니다.

@tsvetomir 는 오랜 .NET 개발자이자 열정적인 C# 프로그래머로서 근본적으로 동의하지 않습니다.

인용한 기사는 권위가 없으며 TypeScript 팀의 공식 자료를 반영하지 않습니다.

또한 @ahejlsberg 가 수많은 대화, 인터뷰 및 게시물에서 언급한

또한 인용된 기사의 관점은 TypeScript의 본질에 대한 근본적인 오해를 반영합니다.
아이러니하게도 C#이 TypeScript와 갖는 공통점은 실제로 JavaScript에서와 동일합니다.
이러한 공통점은 클래스 기반 프로그래밍이 아니라 클로저 및 고차 함수와 같은 구성입니다.

C#이든 아니든 TypeScript가 Javascript의 프로토타입 기능에 더 가까워지는 데 도움이 되는 부분 클래스가 필요합니다.

@yahiko00
TypeScript에는 이미 JavaScript의 모든 프로토타입 기능이 있습니다.
슈퍼세트입니다.

TypeScript의 부분 클래스 개념에는 다음과 같은 몇 가지 문제가 있습니다.

1. C#과 달리 TypeScript(JavaScript) 클래스 정의는 선언적이 아니라 필수입니다. 선언적으로 보이지만 그렇지 않습니다. 이것은 그들이 결정적 실행 순서에 의존한다는 것을 의미합니다.
2. ECMAScript 모듈 시스템은 논리적 코드 단위가 아닌 물리적 코드 단위 가져오기를 기반으로 합니다.
   예를 들어 내가 가지고 있다고 가정 해 봅시다.

_app/my-class-part-1.ts_

TypeScript export partial class MyClass { firstName = "John"; lastName = "Smith"; }

그리고
_app/my-class-part-2.ts_

TypeScript export partial class MyClass { fullName = this.firstName + ' ' + this.lastName; }

이 클래스를 어떻게 가져올 수 있습니까? 어느 모듈에서도 가져올 수 없으므로 다음을 작성할 수 있는 TypeScript의 가상 추상화를 상상해 보겠습니다.
_앱/메인.ts_

TypeScript import { MyClass } from './my-class';

이것은 무엇을 의미할까요? TypeScript 컴파일러가 _app/my-class-part-1.ts_가 _app/my-class-part-2.ts_보다 먼저 로드되어야 한다고 유추할 수 있더라도 개별 부분의 가져오기를 무효화하거나 보장할 수 없습니다. 그것들은 RequireJS와 같은 비동기 모듈 로더에 의해 올바른 순서로 가져오거나 결국 브라우저에서 구현될 것입니다.

부분 클래스의 전체 개념은 근본적으로 ECMAScript 모듈 시스템과 모순됩니다.

업데이트: 임의로 복잡한 종속성 추론을 수행하고 매우 이상한 JavaScript를 내보내야 합니다.

TypeScript에는 이미 JavaScript의 모든 프로토타입 기능이 있습니다.
슈퍼세트입니다.

더 잘 표현했어야 했다. 물론 TypeScript가 JavaScript의 상위 집합이라는 것은 모두 알고 있습니다. 하지만 Partial 클래스는 TypeScript 클래스가 JS 프로토타입에 더 가까워지는 데 도움이 될 것이라고 말하고 싶었습니다. 현재로서는 "정적" 및 확장 불가능한 클래스만 가질 수 있지만 프로토타입 접근 방식을 사용하면 클래스와 유사한 기능을 확장할 수 있습니다.

부분 클래스를 가져오면 내가 동의하는 현재 ES6 구문이 확장됩니다. 우리는 다음과 같이 상상할 수 있습니다.

import { MyClass } from ['app/my-class-part-1', 'app/my-class-part-2'];

TypeScript 클래스는 ECMAScript 클래스를 기반으로 하므로 후자의 표현력 부족으로 어려움을 겪습니다. 함수, 모듈, "네임스페이스" 또는 일반 개체를 사용하여 필요한 것을 수행하는 것을 고려하십시오.

함수는 클래스 개념으로 피하고 싶은 것입니다.
모듈이나 네임스페이스는 단순한 확장성을 가져오고 TypeScript의 클래스와 같은 표현력을 갖지 않습니다. 또한 네임스페이스나 모듈은 인스턴스화할 수 없습니다. 클래스와 동일한 목적을 수행하지 않습니다.

@aluanhaddad 모듈과 관련하여 무슨 말씀이신지 export partial class 에 허용하고 나머지는 partial class 정의만 포함하는 것입니다. 내보낸 곳에서 가져옵니다. 귀하의 예에서 :

_app/my-class.ts_

export partial class MyClass {
    firstName = "John";
    lastName = "Smith";
}

_app/my-class.part.ts_

partial class MyClass {
    get fullName(): string {
        return this.firstName + ' ' + this.lastName;
    }
}

_앱/메인.ts_

import { MyClass } from './my-class';

누락된 것은 컴파일러가 부품을 찾을 위치를 알려주는 구문입니다. 이것은 모든 파일을 한 번에 처리하는 C#의 문제가 아닙니다. 이것은 선언 병합에 사용되는 것과 같은 특별한 구문일 수 있습니다.

임의의 정의를 허용하는 부분 클래스는 필요하지 않습니다. 예를 들어 메서드, 속성 및 생성자로만 제한될 수 있습니다. 이것은 실행 순서를 중요하지 않게 만들고 멤버가 중복되는 경우 컴파일러에서 오류를 던질 수 있도록 합니다.

Module Augmentation 이 이러한 시나리오에 유효하지 않은 이유를 알 수 없습니다. Rxjs5에서는 매우 잘 작동했습니다.

기본 클래스를 생성한 다음 코드 생성과 함께 기본 클래스 위에 필요한 모든 증강 메서드를 생성하기만 하면 됩니다. 생성된 코드가 예쁘더라도 아무 인간도 작성해서는 안 됩니다.

부분 수업을 완벽하게 대체합니까? 나는 그렇지 않다고 생각하지만 ECMAScript가 JavaScript가 필요하다고 결정하지 않는 한 부분 클래스가 발생하는 것을 볼 수 없습니다. 부분 클래스가 외부 모듈 사이에 어떻게 연결되어 있는지에 대한 의미론만으로도 머리가 아픕니다.

@david-driscoll을 더 좋게 만들기 위해 추가된 메서드는 더 강력한 유형 검사를 위해 this: 인수를 선언할 수 있습니다.

Module Augmentation 의 인용된 예에서:

// observable.ts stays the same
// map.ts
import { Observable } from "./observable";
declare module "./observable" {
    interface Observable<T> {
        map<U>(f: (x: T) => U): Observable<U>;
    }
}
Observable.prototype.map = function (this: Observable, f) {
    // here "this" has the shape of the "Observable" class
}

응. Rxjs는 2.0 기능이고 2.0이 아직 릴리스되지 않았기 때문에 아직 조용히 사용하지 않습니다. 그것은 나중에 내 히트 목록에 있습니다.

나는 당신이 모듈에 대해 무엇을 의미하는지 알 수 있습니다. 가능한 솔루션은 파일 중 하나만 부분 클래스를 내보내고 나머지는 부분 클래스 정의만 포함하도록 허용하는 것입니다. 내보낸 곳에서 가져옵니다. 귀하의 예에서 :

_app/my-class.ts_

export partial class MyClass {
    firstName = "John";
    lastName = "Smith";
}

앱/my-class.part.ts

partial class MyClass {
    get fullName(): string {
        return this.firstName + ' ' + this.lastName;
    }
}

나는 구문적 개념을 좋아하지만 문제는 일종의 암시적 모듈로 소비되고 스크립트처럼 보이고 특정 방식으로 로드되어야 하는 새로운 _종류_의 소스 파일을 방금 도입했다는 것입니다.

누락된 것은 컴파일러가 부품을 찾을 위치를 알려주는 구문입니다. 이것은 모든 파일을 한 번에 처리하는 C#의 문제가 아닙니다. 이것은 선언 병합에 사용되는 것과 같은 특별한 구문일 수 있습니다.

선언 병합은 소스 파일이 아닌 _declarations_에 대해 작동합니다.

임의의 정의를 허용하는 부분 클래스는 필요하지 않습니다. 예를 들어 메서드, 속성 및 생성자로만 제한될 수 있습니다. 이것은 실행 순서를 중요하지 않게 만들고 멤버가 중복되는 경우 컴파일러에서 오류를 던질 수 있도록 합니다.

이 모든 것은 _are_ 일반적으로 순서에 따라 다릅니다.

편집: 즉, 정의하면 클래스가 수정됩니다.

아마도 누군가가 이미 이것을 언급했을 것입니다. 그러나 또 다른 유용한 경우는 일부 코드 생성기에서 클래스의 일부를 생성한 다음 구현에 직접 수동으로 더 많은 코드를 추가하려는 경우입니다.
당신은 정말로 믹싱이나 파생 클래스를 원하지 않습니다.
여전히 하나의 클래스입니다. 일부는 자동으로 다른 일부는 수동으로 생성됩니다.

BTW: 누군가 C# 클래스에서 TS 유형을 생성해야 하는 경우 TypeScriptBuilder 를 확인할 수 있습니다.

고려해 주셔서 감사합니다!

TypeScriptBuilder를 사용해 보겠습니다. ;)

나의 제안...

컴파일러가 모든 부분을 찾으려고 하지 않으면 어떻게 될까요? 다른 부품을 가져와서 모든 것을 제어해야 한다면 어떻게 될까요?

/MyClass.partial.ts

export partial class MyClass {
    firstName = "John";
    lastName = "Smith";
}

MyClass.ts

// v- this would NOT throw an error because the definition is marked as partial
import { MyClass } from "./MyClass.partial";

export class MyClass {
    get fullName(): string {
        return this.firstName + ' ' + this.lastName;
    }
}

그 다음에...

1. 내가 사용하려는 경우 MyClass 나는로부터 가져올 필요가 MyClass.ts
2. 컴파일되면 MyClass.partial.ts 는 이전에 여기에 표시된 것처럼 MyClass.prototype 를 확장하는 자바스크립트를 생성합니다. 그러나 확장할 프로토타입을 받는 함수를 내보냅니다.
3. MyClass.partial.ts MyClass 가 정의된 후 MyClass MyClass MyClass.partial.ts 를 import 하고 확장 함수를 호출합니다.

참고로... 컴파일된 코드를 직접 생성하는 것을 방해하는 것은 없습니다. 그러나 나는 Typescript의 모든 위대함을 잃어버렸습니다.

@svallory 나는 그것이 확실히 올바른 접근 방식이라고 생각합니다. 특히 생성된 코드가 기능 보강을 유발하는 함수를 내보낼 것이라고 말했기 때문에 함수가 필요한 결정적 순서로 호출될 수 있기 때문에 비동기 가져오기에서도 작동합니다.

더 일반적으로, 참조된 문제를 잊어버렸습니다. 클래스 프로토타입에 대한 할당이 클래스의 모양에 영향을 준다면 많은 이점이 있을 수 있습니다. 이것은 믹스인 라이브러리를 개선하고 데코레이터를 훨씬 더 유용하게 만들고 일반적으로 수직 계층을 덜 권장합니다.

컴파일러가 이 모든 것을 추적하는 것은 까다로울 수 있지만 아마도 당신이 제안한 대로 명시적으로 작동하도록 만들 수 있습니다.

부분 클래스 사용 사례가 해당 개선 사항에서 빠지면서 유형 시스템의 개선 사항이 될 것입니다.

저는 다음과 같이 했습니다.

나는 다음과 같이 그것을했다 :
 파일1 . TS
 인터페이스 ifoo {
 a ( ) : 무효 ;
 }
 클래스 foo는 ifoo {를 구현합니다.
 a ( ) { /*무언가를 하세요*/ }
 }
 파일2 . TS
 /// <참조 경로="file1.ts" /> //필요하지 않음
 인터페이스 ifoo {
 b ( ) : 무효 ;
 }
 푸 . 프로토타입 . b = ( ) = > { /*무언가를 수행*/ }
 파일3 . TS
 /// <참조 경로="file1.ts" /> //필요하지 않음
 인터페이스 ifoo {
 c ( ) : 무효 ;
 }
 ( < ifoo > foo . 프로토타입 ) . c = ( ) = > { /*무언가를 수행*/ }
 소비자 . TS
 /// <참조 경로="file1.ts" />
 /// <참조 경로="file2.ts" />
 /// <참조 경로="file3.ts" />
 f = 새로운 foo ( ) ;
 에프 . ( ) ;
 에프 . 나 ( ) ;
 에프 . c ( ) ;

Module Augmentation은 여전히 ​​여기서 문제의 90%를 해결합니다. @svallory 의 예가 주어

/MyClass.partial.ts

export partial class MyClass {
    firstName = "John";
    lastName = "Smith";
}

MyClass.ts

// v- this would NOT throw an error because the definition is marked as partial
import { MyClass } from "./MyClass.partial";

export class MyClass {
    get fullName(): string {
        return this.firstName + ' ' + this.lastName;
    }
}

모듈 보강은 다음과 같을 것입니다 ...

MyClass.ts

export class MyClass {
    firstName = 'John';
    lastName = 'Smith';
}

MyClass.generated.ts

import { MyClass } from './test';

Object.defineProperty(MyClass.prototype, "fullName", {
    get(this:MyClass) {
        return this.firstName + ' ' + this.lastName;
    }
});

declare module './test' {
    interface MyClass {
        readonly fullName: string;
    }
}

부분 클래스보다 조금 더 장황하지만 실제로 부분 클래스는 이 구현을 위한 구문 설탕일 뿐입니다.

오늘날 당신이 가지고 있지 않은 유일한 문제는 다음과 같습니다.

• this: MyClass 구문을 사용하여 개인 또는 보호 필드에 액세스할 수 없습니다.
  
  
  
  • 이것은 any 로 캐스팅하여 생성된 코드에서 쉽게 해결할 수 있습니다.
  
  
  • 아마도 이것은 this 의 보호된 구성원에 액세스할 수 있도록 추가할 수 있는 것입니다. 그와 관련된 다른 규칙이 있을 수 있습니다.
  
  
• 생성된 코드는 조금 더 위협적으로 보이지만 소비자의 경우 일단 기능이 강화되면 그 차이를 결코 알지 못할 것입니다.

편집: 이것은 TS 2.0+ 구문임을 명심하십시오.

@david-driscoll 동의합니다. 나는 그것이 더 간단하고 추가 구문을 도입하지 않는 것을 좋아한다고 생각합니다. 아시다시피 저는 부분 클래스를 특정 언어 기능으로 사용하는 것을 반대하지만 TypeScript가 일반적으로 프로토타입에 대한 할당을 추적하고 그에 따라 개체의 모양을 다듬는 것이 도움이 될 것이라고 생각합니다. 귀하의 접근 방식이 여러 파일에 클래스를 분할하는 올바른 방법이라고 생각합니다.

@wongchichong 귀하의 예제는 전역 클래스 이름과 /// <reference path="..."/> 합니다. 상황을 개선하기 위해 네임스페이스를 사용할 수는 있지만 확장성이 좋지 않을 것이라고 생각합니다.
모듈로 작성된 코드(즉, 외부 모듈)는 순서 종속적이고 암시적인 종속성을 인식해야 하는 로더를 포함하기 때문에 매우 다른 짐승입니다. 이것이 @svallory 의 제안이 가치 있는 이유

누군가가 모듈을 사용하지 않는다면?

@pankleks 부분 클래스는 여전히 나쁜 생각입니다.

명확히 하자면, 클래스 선언이 선언적이 아닌 필수인 JavaScript와 같은 언어에서는 나쁜 생각입니다. 네임스페이스를 사용하는 경우에도 코드를 여러 파일로 분할하게 되므로 이 파일이 전혀 작동하려면 해당 파일의 스크립트 태그 순서에 의존해야 합니다.

C#과 같은 언어에서 부분 클래스는 잘 작동하지만 이는 JavaScript의 클래스와 근본적으로 다르기 때문입니다.

JavaScript에서 클래스 선언은 선언적은 고사하고 호이스팅되지도 않는다는 것을 기억하는 것이 중요합니다.

ES6을 제외하고 "클래스" 개념은 TS에서 정의합니다. JS에는 _전혀__ 클래스에 대한 개념이 없습니다.
따라서 클래스가 무엇인지 결정하는 것은 TypeScript의 몫입니다.

ES6 제외,

TS 언어 기능을 논의할 때 ES6을 금지할 수 없습니다. TS 목표 중 하나가 현재/미래의 ES 사양을 따르는 것이기 때문입니다.

사실입니다 :/

코드 생성 클래스(예: 엔터티, 서비스 계층 클라이언트 등)가 있는 대규모 시스템의 경우 C# 디자인에 따른 부분 클래스는 생성된 코드를 추가 상태 및 동작으로 확장해야 할 때 매우 우아한 솔루션을 제공합니다. ~500개의 코드 생성 클래스가 있는 현재 프로젝트에서 이 기능이 그리워집니다.

나는 여전히 일부 사람들이 "나쁜 생각"이라고 말하는 것을 제외하고는 다른 곳에서 유용하다고 입증된 기능에 대해 그렇게 적대적인 이유를 이해하지 못합니다.

이것은 esdiscuss에서 많이 논의되지 않은 것 같습니다. 내가 찾은 유일한 스레드 에는 9개의 게시물이 있습니다.

@yahiko00 제가 그 컨셉에 적대적인 것은 아닙니다. 당신이 말했듯이 C #과 같은 언어에서 매우 유용합니다.

열성적인 C# 프로그래머인 저는 부분 클래스가 특정 작업에 매우 유용하다는 것을 알았습니다. 그러나 그들은 언어의 다른 측면을 방해하지 않습니다. 네임스페이스, 어셈블리 및 임의로 정렬 가능한 형식 선언과 같은 주요 관련 추상화를 중단하지 않습니다.

반면에 JavaScript는 기껏해야 초기 단계인 모듈 시스템을 가지고 있습니다. 수업은 새롭고, 아직 언어의 표현력이 그다지 뛰어나지는 않지만 성장하는 데 시간이 필요하다고 생각합니다.

잠시 뒤로 물러나 C#의 또 다른 강력하고 훨씬 더 유용한 기능인 확장 메서드를 고려한다면 JavaScript에 추가되는 것을 보고 싶지만 그렇게 하는 데에는 아직 해결되지 않은 근본적인 문제가 있습니다.

모듈과 같은 훨씬 더 기본적인 개념을 깨거나 심하게 제한하지 않고 부분 클래스를 지정할 수 있는 지점에 도달하면 저는 모두 이를 추가하는 데 찬성할 것입니다.

즉, @SaschaNaz가 지적했듯이 ECMAScript에서 이 _does_를 해결해야 합니다.

관심 있는 사람은 http://esdiscuss.org 에서 새 스레드를 열고 여기에 URL을 게시하여 토론을 계속할 수 있습니다. 😄

추신: 또는 GitHub와 유사한 ES Discourse에서 .
PS2: 또는 GitHub와 유사하고 더 활동적인 WICG에서 .

나도 TS용 코드 생성을 허용하는 일부 구성을 보고 싶습니다. 부분 클래스는 C#에서 이에 적합합니다.

어쩌면 내가 뭔가를 놓치고 있을지 모르지만 핵심 문제는 생성자가 아닌 다른 곳, 가급적이면 다른 파일에서 '비공개' 변수에 액세스할 수 있는 클래스를 확장하는 것입니다.

논의에 따르면 '안전한' TS 혁신이 많이 완료된 것으로 보입니다. 이제 우리는 앞으로 아무 것도 깨뜨리고 싶지 않기 때문에 ES 거버넌스 기구가 무엇을 하는지 보기만을 기다리고 있습니다. 완전히 유효하지만 TS로 더 빨리 움직이는 기차를 바랐기 때문에 약간 낙담했습니다.

전제 조건은 좋은 디슈가링을 찾는 것입니다 .

이전에는 클래스에 직접 추가할 수 있기 때문에 부분 클래스가 꽤 어리석다고 생각했지만, 그렇게 하면 메서드를 열거할 수 없게 만들고 슈퍼 바인딩을 수정하는 작업이 포함된다는 점을 감안할 때 매력을 볼 수 있습니다(후자는 현재 ES6).

우리는 먼저 기존 toMethod와 같은 구성적, 명령적 기본 요소로 일반적으로 클래스에 대한 적절한 구어를 알아낼 필요가 있습니다. 그러나 일단 우리가 그것을 갖게되면 부분 클래스와 같은 상단에 더 많은 설탕을 추가하는 것이 인체 공학적이거나 그렇지 않은 정도에 따라 합리적 일 수 있습니다.

이것이 정확히 무엇을 의미하는지 확실하지 않지만 아마도 다음과 같을 것입니다.

class A {
  foo() { return "foo" }
}
class B extends A {
}

partial(B, class {
  get foo() {
    return super.foo(); // should work
  }
});

( esdiscuss 에 십자가 게시 )

순수 JS에서 부분 클래스를 구현하는 상당히 간단한 방법이 있는 것 같습니다( ES2017 getOwnPropertyDescriptors 사용 ). ES 사람들은 이 작은 코드를 제거하는 데 구문 설탕이 필요하지 않을 것이라고 생각할 수도 있습니다.

function partial(base, extension) {
  extension.prototype.__proto__ = base.prototype.__proto__; // to enable 'super' reference
  const descriptors = Object.getOwnPropertyDescriptors(extension.prototype);
  delete descriptors.constructor; // must not override constructor
  Object.defineProperties(base.prototype, descriptors);
  
  return base;
}

물론 TS에서 이것을 사용하려면 기존 클래스 유형을 확장하기 위해 interface 중복이 필요합니다.

@SaschaNaz getOwnPropertyDescriptors를 통해 생성자에 추가된 속성은 IDE "자동 제안"에 대해 숨겨질 것으로 예상합니다(런타임에 추가되기 때문에). Typescript는 "autosuggestion"이 있는 JavaScript로 태어났습니다(때때로 사람들은 이것을 "strongly typed"라고 부르지만 실제로 그들이 좋아하는 것은 "autosuggestion"입니다).

추신 사람들에게 부분 클래스가 필요한 이유 - 코드 생성. 그러나 다시 코드 생성은 IDE(소스 파일에 대한 쉬운 "도구" 조정, 파일 탐색기의 계층적 결과, T4 또는 유사한 "공통 코드 생성기" 지원) 및 언어(부분 클래스, 확장 메서드) 모두에서 지원되어야 합니다. 이것을 이해한 후에야 개발자가 실제로 무엇을 요구하는지 이해할 수 있게 됩니다. 전체 그림을 볼 수 없다면 물론 "부분 수업"은 "넌센스"처럼 보입니다.

@aluanhaddad : 하지만 TypeScript의 주요 기능은 JavaScript에 없는 언어 요소를 제공하는 것 아닙니까? 클래스를 두 개의 부분 TypeScript 파일로 분할하여 단일 JavaScript 파일로 컴파일하는 것이 왜 나쁜 생각입니까?

커뮤니티에 도구를 제공하는 데 문제가 있다고 생각하지 않습니다. 그리고 그것을 오용할 개발자가 있을 것이라고 100% 확신합니다. 그러나 그것을 사용하는 방법을 정확히 알고 있는 개발자도 있습니다. 그러나 우리는 어떤 언어의 어떤 구성에서도 같은 상황에 처하지 않습니까?

코드 생성 목적으로 +1. 그리고 저는 @rpokrovskij 에 동의합니다. 왜

@greendimka ES 모듈에서 벗어나 상당한 복잡성을 추가하지 않고 이것이 어떻게 작동할 수 있는지 모르겠습니다.

@xiexin36 TypeScript는 확실히 C#보다 JavaScript에 더 가깝습니다.
JavaScript와 C# 사이에는 공통점이 있지만 class 의 개념은 완전히 다릅니다.

코드 생성을 위해 @xiexin36 을 사용하면 여전히 모듈 확장을 사용할 수 있습니다( 이 스레드의 앞부분에서 언급

@aluanhaddad 글쎄, 그것은 매우 간단하게 작동합니다. 부분 클래스는 어떤 식으로든 코드 구조를 변경하지 않습니다. 그것들은 우리가 (어쨌든 단일 JS로 컴파일된) 여러 파일에 동일한 클래스의 정의를 작성할 수 있도록 합니다.

@aluanhaddad 엄밀히 말하면 자바스크립트에는 클래스 개념이 없습니다(ES6 클래스는 단지 합성 설탕을 제공함). 따라서 TypeScript가 JavaScript만큼 취약하다는 개념을 따르려고 하면 TypeScript에서 클래스를 버려야 하지 않을까요? 우리는 단순히 JavaScript로 되돌려야 하지 않습니까?

@greendimka ES6 클래스와 TypeScript 클래스는 하나이며 동일합니다.
TypeScript는 JavaScript의 런타임에 추가 구성을 추가하는 것을 목표로 하지 않습니다.

ES6 클래스는 _매우_ 부족합니다. 그렇다고 JavaScript가 강력한 언어가 아니라는 것은 아닙니다. TypeScript는 정적 타이핑을 제공하여 설계 시 오류를 포착하고 고품질 도구를 제공하며 구성 요소 인터페이스의 매우 정확하고 엄격한 사양을 허용하고 일반적으로 생산성을 향상시킵니다.

ES6 클래스는 _매우_ 부족하지만 TypeScript가 자체 클래스 개념을 도입하는 것은 설계 목표를 직접적으로 위반하는 것입니다.

단순히 수업을 피하면 문제가 해결됩니다.

글쎄, 그것은 매우 간단하게 작동합니다. 부분 클래스는 어떤 식으로든 코드 구조를 변경하지 않습니다. 그것들은 우리가 (어쨌든 단일 JS로 컴파일된) 여러 파일에 동일한 클래스의 정의를 작성할 수 있도록 합니다.

그리고 인간에게 알려진 거의 모든 도구를 부수나요? 아니요 괜찮습니다.

@david-driscoll 감사합니다. 시도해 보겠습니다. 하지만 Angular 2.0도 사용합니다.
@Input 또는 @Output , 작동할 것입니다. 어쨌든 시도해 볼 것입니다.

@aluanhaddad "클래스? javascript에는 클래스가 없습니다"를 반복하는 데 어떻게 매달 스러운 일입니다. 머리에서 클래스를 제거하고 JavaScript만 남겨두고 이제 들어보십시오. 코드 생성을 사용하는 개발자는 여러 파일에 하나의 컴파일 단위를 갖고 싶어합니다. 이 언어에는 클래스가 없고 함수만 있습니까? 좋아, 우리는 부분적인 기능을 원한다. 그리고 JavaScript는 이에 대한 준비가 거의 완료되었습니다. 선언 전에 사용할 수 있는 함수입니다. 물론 거기에서 다른 문제를 만날 수 있습니다(예: 모든 부분/파일이 실행 환경에 로드되었는지 확인). 그러나 해결할 수 있으며 실제로 JavaScrpipt가 아닌 TypeScript에서 부분 컴파일 단위를 원합니다. Typescript는 이를 100% 준비했습니다.

그런데 TypeScript 팀에서 일부 기능도 제공합니다! 그리고 지금은 "함수에 함수"가 있으므로 C# 팀에도 똑같이 알려주세요. :)

확실히 하기 위해 부분 함수는 매우 구체적인 의미를 가지고 있으며 당신이 설명하는 것은 상상의 여지 없이 부분 함수가 아니라는 것을 알고 있습니까?
코드 생성은 유용합니다. 저도 사용합니다.

@알루안하다드 . "여러 파일의 하나의 컴파일 단위"라는 용어를 이해합니까? Javascript는 물론 컴파일 언어가 아니지만 a) 함수는 실행 전에 완전히 구문 분석되어야 하며 이 이름을 "컴파일"이라고 할 수 있습니다. b) Typescript는 컴파일 언어입니다.

당신의 상상력을 돕기 위해:

function partial func(arguments) {
  return function() {
    return codegenerated(arguments);
  };
}

function partial func(arguments) {
   function codegenerated(arguments){
      // ...
   }
}

또한 부분 클래스를 자주 사용하지 않습니다. 이를 효과적으로 사용하려면 코드 생성 매개변수를 "수동" 부분에 저장해야 하고 이 구성을 읽으려면 좋은 언어 파서(반사 아님)가 있어야 합니다. 하지만 그 방법은 다음과 같습니다. 부분 클래스는 코드 생성을 편안하게 만드는 많은 도구 중 하나일 뿐입니다.

@rpokrovskij
제가 적대감으로 나왔다면 사과드립니다. 나는 모욕이나 무례를 의미하지 않았습니다.

귀하의 예에는 그 자체로 상당히 공식적인 설명이 필요한 측면이 있습니다. 이 제안은 원래 코드 생성 시나리오를 직접 활성화하는 것이 아닙니다.

@aluanhaddad....
"수업을 피하면 문제가 해결됩니다." - 진지하게, 그것이 문제의 해결책?! 아마도 JavaScript 사용을 피한다면 이 전체 토론의 문제를 해결할 수 있습니다. 역시 해결책이겠죠? 불행히도 우리 우주에는 이 엉터리 언어가 있습니다. 왜냐하면 몇 년 전에 웹에 들어갈 수 있을 만큼 운이 좋았기 때문입니다. 어쨌든 이것은 주제를 벗어난 것입니다.

"사람에게 알려진 거의 모든 도구를 부수다" - 그게 어떻게 가능한가요??? 어떻게?!?! TypeScript에서 부분 클래스를 사용하여 무언가를 깨는 것을 상상하려고 시도하지만 그렇게 할 수 없습니다. 나는 단순히 할 수 없다. 실생활의 예를 들어 여기에서 저를 도와주세요.

이제 상자를 운반하기 위해 자동차를 만들었다고 상상해 보십시오. 문제 없이 작동합니다. 당신은 차에 짐을 싣는 직원을 고용합니다. 작업자는 한 번에 두 개의 상자를 가져와 차에 싣습니다. 여전히 모든 것이 잘 작동합니다.
어느 날 직원이 다른 회사로 떠나고 당신은 새 회사를 고용합니다. 새 제품은 단일 상자를 가져와서 로드하고 다른 단일 상자를 가져와서 로드합니다. 논리적으로: 모든 것이 정상입니다. 하지만 당신은 뛰어다니며 소리를 질렀습니다. 그만, 그만, 시스템 오류가 발생했습니다! :)

"수업을 피하면 문제가 해결됩니다." - 진지하게, 그것이 문제의 해결책?! 아마도 JavaScript 사용을 피한다면 이 전체 토론의 문제를 해결할 수 있습니다. 역시 해결책이겠죠? 불행히도 우리 우주에는 이 엉터리 언어가 있습니다. 왜냐하면 몇 년 전에 웹에 들어갈 수 있을 만큼 운이 좋았기 때문입니다. 어쨌든 이것은 주제를 벗어난 것입니다.

ES2015는 확실히 잘못된 점이 많습니다. ES5.1은 확실히 잘못된 점이 많았습니다. 제 생각에는 수업이 부족한 것도 그 중 하나가 아니었습니다. 내 요점은 공개 모듈 패턴과 같은 기술을 사용하면 부분 클래스가 필요 없다는 것입니다. TypeScript는 표시 모듈 패턴, 네임스페이스에 대한 설탕을 제공합니다.

"사람에게 알려진 거의 모든 도구를 부수다" - 그게 어떻게 가능한가요??? 어떻게?!?! TypeScript에서 부분 클래스를 사용하여 무언가를 깨는 것을 상상하려고 시도하지만 그렇게 할 수 없습니다. 나는 단순히 할 수 없다. 실생활의 예를 들어 여기에서 저를 도와주세요.

ES 모듈을 사용하는 경우 이는 문제가 됩니다. 컴파일되지 않은 대응물과 일치하는 컴파일러의 물리적 아티팩트에 의존하는 모든 도구는 이에 종속됩니다. 즉, TypeScript는 방출에서 이를 조정할 수 있으며, 이는 대규모 변경이지만 사용자가 작성한 TypeScript와 일치하지 않는 JavaScript를 방출하게 됩니다.

따라서 기본적으로 언어의 진화는 언어의 진화 없이는 결코 진화하지 않을 도구에 의해 저지되고 있습니다.
미안하지만 진화하지 않는 이유에 대한 검색만 여기에서 볼 수 있습니다.

부분 클래스가 제공하는 이점은 무엇입니까? 다른 방식으로는 언어로 이미 할 수 없습니다. 물론 좋은 구문 설탕이지만 진정한 이점은 무엇입니까? C#처럼 만드는 것 외에 구체적인 예가 있습니까?

참고로 저는 C# 개발자로 시작한 기록을 위해 그곳에서 JavaScript/C#으로 옮겼습니다. TypeScript 0.8이 발표된 후 제가 판매된 이유는 JavaScript용 C#이기 때문이 아니라 엄격한 JavaScript를 사용하고 강력한 C# 유형을 즐기는 개발자에게 더 적합하게 만들기 때문입니다.

TypeScript는 C#이 아니며 C#에 기능이 있다는 이유만으로 C#에서 기능을 엄격하게 상속해서는 안 됩니다. C#이 TypeScript에서 기능을 상속해서는 안 되는 것처럼. TypeScript에서는 매우 훌륭하지만 아직 언어에는 적합하지 않기 때문에 C#에서 공용체 유형과 같은 기능을 원했던 시간을 셀 수 없습니다.

지금까지 코드 생성 및 코드 구성을 읽었습니다.

Code Generation, Module Augmentation을 보세요. 여기에 제가 언급한 몇 가지 결함이 있지만 고칠 수 있다고 확신합니다.

코드 조직, 지역을 사용하는 것 같아요 (웃음)? 코드를 구성하는 다른 많은 방법이 있습니다. 하나의 God 클래스가 있는 경우(어떤 이유로든) 항상 여러 God 클래스로 나눌 수 있습니다. 표면적으로 god 클래스는 모든 사람이 보고 사용하는 가져오기이지만, 겉으로는 God 클래스의 속성으로 많은 클래스로 구성되어 있습니다. 조직을 위해 부분 클래스를 사용하는 경우 코드를 약간 리팩토링하고 SOLID 코드를 수정해야 한다고 주장합니다.

나는 지금까지 만난 대부분의 코드 생성 시나리오에 기능 보강을 맞출 수 있었습니다.

Omnisharp-Client의 경우 여기 에서 인터페이스 확장을 사용합니다. 여기서 OmniSharp.Api.V2 는 C#의 리플렉션을 통해 생성됩니다. 파일 맨 아래에는 해당 인터페이스에 대한 모든 메서드를 스텁 아웃하는 도구가 있습니다.

RxJS의 경우 Observable 에 있는 모든 메서드 를

부분 클래스의 일부 문제에 대해서는 추론할 수 없습니다. 예를 들어 3개의 부분 클래스가 제공되는 경우.

• MyAwesomeClass1.ts
• MyAwesomeClass2.ts
• MyAwesomeClass3.ts

범위: 글로벌 모듈( namespace / module )

전역 컴파일은 이것이 가장 쉬운 것으로 보이는 곳입니다. TypeScript는 이미 네임스페이스를 병합하기 때문입니다.

내 tsconfig.json 에 Class1 및 Class2에 대한 파일 경로만 포함되어 있으면 Class3에 있는 모든 항목이 자동으로 병합되지 않습니다.

• 처음에는 사용자 오류처럼 보이지만 Class3의 메서드가 포함되지 않은 이유는 즉시 명확하지 않습니다. 이것은 혼란을 야기할 큰 사용성 문제입니다.

범위: 외부 모듈(가져오기/내보내기)

외부 컴파일을 사용하면 각 모듈에는 모든 종속성(가져오기)과 모든 공개 API(내보내기)에 대한 명시적 목록이 있기 때문에 각 파일은 실제로 모듈(또는 .NET 세계에서는 지옥 어셈블리)으로 간주됩니다.

이러한 시나리오에 대해 어떻게 추론합니까?

파일 참조가 하나만 주어지면 클래스의 동작은 무엇입니까?
Class2와 Class3을 자동으로 병합합니까?

• Class1, Class2 및 Class3의 기본 정의가 모두 정확히 동일한 값을 내보내나요?
• 어떤 파일이 디스크로 내보내집니까?
• 지원되는 모든 형식(amd, umd, commonjs 등)에 대한 기본 JavaScript는 어떻게 생겼습니까?

// somefile.ts
import { MyAwesomeClass } from 'MyAwesomeClass1';

new mac = new MyAwesomeClass();
mac. // What methods are available here?

클래스의 모든 인스턴스를 명시적으로 가져와야 합니까? (만약 그렇게 하면 목적이 무산됩니다).
한 파일의 모든 항목을 가져오고 다른 파일은 가져오지 않는 메서드로 가져오면 어떻게 됩니까?
이것은 추가 부분 없이 클래스가 한 번 사용되는 복잡한 종속성 그래프를 고려할 때 정말 이상한 오류로 이어질 수 있습니다. 값이 증가할까요? 아니면 메소드를 불러오는 다른 파일이 로드될 때까지 메소드가 마술처럼 작동하지 않습니까?

// somefile.ts
import { MyAwesomeClass } from 'MyAwesomeClass1';
import { MyAwesomeClass } from 'MyAwesomeClass2'; // or maybe import 'MyAwesomeClass2';
import { MyAwesomeClass } from 'MyAwesomeClass3'; // or maybe import 'MyAwesomeClass3';

new mac = new MyAwesomeClass();
mac. // What methods are available here?

@david-driscoll 여기 내 2센트만:

물론 좋은 구문 설탕이지만 진정한 이점은 무엇입니까?

좋은 구문 설탕은 모든 언어의 요점이 아닙니까? 작동적인 관점에서 우리에게 필요한 것은 루프, if-절 및 모든 것을 수행하는 반복뿐입니다. 나머지는 생산성을 높이고 다른 유사한 비기능적 특성을 제공하기 위한 _좋은 구문 설탕입니다.

그리고 언어는 일반적으로 컴퓨터에 지시하는 조작적인 부분에 능숙하지만 일반적으로 코드를 작성하는 조직적인 부분에서는 부족합니다. 우리는 객체, 클래스, 상속 등과 같은 문화적 임시 인공물을 가지고 있지만 조직 작업의 영역과 우리가 구성하고 소스 코드에서 순서대로 나타내려고 하는 모든 추상화를 실제로 설명하는 견고한 이론적 토대인 afaik은 없습니다. 좋은 방법으로 작업할 수 있습니다.

TypeScript에 대해 좋아하는 두 가지가 있습니다. 1. 유형이 지정된 자바스크립트를 사용하여 클라이언트에서 복잡한 시스템을 갑자기 관리할 수 있게 해줍니다. 2. 유형 시스템은 매우 표현력이 뛰어납니다(유형 시스템의 제한 없이 사람들이 작성할 수 있는 모든 종류의 패턴을 자바스크립트로 표현할 수 있도록 강요받았기 때문입니다).

그러나 코드를 구조화하는 것과 관련하여 다른 언어보다 훨씬 덜 번거롭다고 생각하지 않습니다. 여기에서 더 혁신적일 수 있기를 바랍니다. 사용자가 언어의 조직적인 부분을 실험할 수 있는 더 많은 자유를 제공합니다. 제한적이고 의심스러운 것이 아니라 새로운 구조적 표현력을 개방하고 추구합니다.

Partial 클래스는 특히 코드 생성에 매우 편리할 뿐만 아니라 일반적으로 조직의 자유도를 높입니다. 코드 조직의 타르핏에서 벗어나기 위해 필요한 자유입니다.

@david-driscoll 부분을 갖는 요점은 무엇입니까? 음, 다시 한 번: 코드 생성.
제안한 솔루션의 문제점은 무엇입니까? 해결 방법입니다. 또 다른 해결 방법(그리고 꽤 더러운 해결 방법). 우리는 이미 해결 방법으로 가득 찬 형편없는 언어(javascrtipt)를 가지고 있습니다. 자바스크립트 개발자는 주요 작업에 대해 생각하는 대신 해결 방법에 대해 생각하는 데 많은 시간을 할애합니다. 당신이 제안한 철학으로 우리는 전체 TypeScript 언어를 버릴 수 있습니다. (놀라움, 놀라움) 해결 방법을 사용하여 전체 유형 시스템을 순수한 자바 스크립트로 시뮬레이션할 수 있기 때문입니다. 대안으로 무엇이든 시뮬레이션할 수 있다면 더 표현력이 풍부한 언어(예: Typescript)에 관심을 갖는 이유는 무엇입니까? 같은 내용을 스무 줄로 작성할 수 있는데 왜 한 줄의 코드를 작성합니까? 작성된 코드 줄 수에 따라 급여를 돌려받으세요! 짧고 표현력이 풍부한 코드는 겁쟁이를 위한 것 아닙니까?

그리고 아니오: TypeScript에 부분을 포함하라는 요청은 C#에 부분이 있다는 생각에 기반하지 않습니다. 나는 TypeScript에 다른 언어가 있기 때문에 그것을 갖기 위해 무언가를 가져야 한다고 생각하지 않습니다.

그리고 마지막으로 : 왜 당신이 무언가를 사용하지 않으면 아무도 그것을 필요로하지 않는다고 생각합니까?

@greendimka 저는 적대감을 shield:. 나는 단순히 시나리오를 이해하려고 노력하고 있거나 솔직히 완전히 가능한지 잘 모르는 시나리오가 있는 경우!

이제 저는 TypeScript 팀에 있지 않고 옹호자일 뿐이라는 사실을 명심하세요. 하지만 팀은 여기에서 꽤 침묵했습니다. 팀은 구체적으로 할 말이 있을 때 잘 들을 수 있으며, 그들이 그렇게 하기로 결정하면 나는 그들에게 연기할 것입니다.

TypeScript 팀이 유지한 핵심 테넌트 중 하나는 TypeScript를 ECMAScript의 방향과 동기화하여 계속 움직이도록 하고 JavaScript가 발전하는 전체 방향에서 벗어날 수 있는 특정 기능을 만들지 않도록 하는 것입니다.

사용하지 않는다는 것은 아닙니다(존재한다면 사용하겠습니다). 문제는 이 문제에서 부분 클래스가 경고할 수 있으므로 곧 구현될지 의심된다는 것입니다. a) 높은 가치의 이해 관계자에게 필수 기능이 되거나 b) 제안이 TC39의 후반 단계로 들어갈 때까지 한동안 이 상태를 유지할 것입니다.

나는 Module Augmentation을 해결 방법으로 보지 않습니다. 이를 통해 유형 시스템을 보강할 수 있으며 이 스레드에서 자세히 설명된 많은 코드 생성 시나리오를 사용할 수 있습니다. 이것은 다른 언어 기능을 향한 단계입니다.

• 못생겼어? 절대적으로, 지옥처럼 추악합니다. 코드를 생성하는 경우 차이점은 무엇입니까? 생성 도구만 클래스를 보강하는 방법에 대해 걱정하면 됩니다. 코드 생성 도구를 실행하고 모듈을 포함하면 완전한 인텔리센스 및 컴파일 오류 등이 발생합니다.

• 그것은 완벽합니까? 그것에서 멀리! 언어 수준에서 지원해야 하는 믹스인이 있는 훨씬 더 일반적인 시나리오를 봅니다. 그리고 여기 에서 제안한 데코레이터와 일맥상통하는 것이 타당하다고 생각합니다. 다시 말하지만 구체적인 제안은 없습니다.

@david-driscoll, 매우 무례하게 해서 죄송합니다. 나는 긍정적인 발전의 편에 서는 경향이 있습니다.

부분 클래스에 정적 구현을 ​​넣을 수 있도록 하고 싶습니다.

이것이 곧 실현될 것 같지 않기 때문에 우리가 찾은 해결 방법을 제안하고 싶습니다. 이런 댓글이 몇 개 있긴 한데, 이런 구체적인 내용이 있는 댓글은 본 적이 없습니다.

우리는 생성된 TypeScript 코드를 확장할 수 있기를 원하는 코드 생성 시나리오에서 Partials를 사용하고 싶습니다. 그러나 우리는 상호 의존성을 가진 모델을 생성하므로 클래스에서 상속하는 것은 전통적인 의미에서 잘 작동하지 않습니다. 다른 클래스를 참조하는 생성된 클래스는 참조되는 올바른 유형의 객체로 끝나지 않으며 올바른 인스턴스 유형을 생성하기 위해 복잡한 팩토리 패턴으로 끝납니다.

생성된 클래스를 기본 클래스로 변경했지만 클래스 선언에서만 변경되었습니다. 그런 다음 새 기본 클래스에서 상속된 스텁 클래스를 만들었습니다. 그런 다음 이러한 새 클래스를 확장할 수 있으며 기본 클래스에서 모든 콘텐츠를 상속합니다.

예를 들어:
Person 클래스를 생성했다면 이제 PersonBase를 생성할 것입니다. 생성된 모든 코드는 이 클래스에 포함됩니다. PersonBase를 확장하는 빈 클래스 Person도 생성합니다. 이 클래스는 한 번만 생성됩니다. 그런 다음 생성된 모든 코드를 PersonBase에 넣고 모든 사용자 지정 코드를 수동으로 Person에 넣습니다. Person에 대해 생성된 모든 참조는 PersonBase가 아닌 Person으로 유지됩니다. 이렇게 하면 모든 IntelliSense가 계속 작동합니다.

파일 1: 기본 클래스

module ViewModels {
    export class PersonBase {
        // Generated members
        public anotherPerson: Person;
        constructor(){
            // Generated constructor code
        }
    }
}

파일 2: 실제 클래스

module ViewModels {
    export class Person extends PersonBase {
        // Custom methods
        public NewVariable: string = "NewVar";
        constructor() {
            super();
            // Custom constructor code
        }
    }
}

이것은 생성된 코드에 대한 부분 클래스 문제를 해결했습니다. 아이디어를 생각해 낸 Andrew Scott에게 경의를 표합니다.

코드 생성기로 일부 코드를 생성하고 있고 여기에 몇 가지 변경 사항을 추가해야 하기 때문에 이것도 정말 원합니다. 부분 클래스를 사용하면 나중에 변경 사항을 다시 추가하지 않고도 코드를 다시 생성할 수 있습니다(크거나 복잡할 수 있음).

아직 언급되지 않은 부분 클래스가 있어야 하는 중요한 이유가 있습니다. JS를 TS로 점진적으로 마이그레이션하는 것입니다. Javascript, 특히 pre-ES6에서 클래스는 다음과 같이 보일 수 있습니다.

Foo.prototype.someFunction = function() {/*....*/}

그리고 이들은 특별한 처리 없이 여러 파일에 퍼질 수 있습니다. 이와 같은 코드베이스를 최신 TypeScript로 변환하려면 현재 클래스의 모든 구성원이 동일한 파일에 있도록 함수를 이동해야 하며, 이는 상당히 침입적인 변경이 될 수 있습니다. 부분 클래스를 사용하면 로컬 편집만 사용하여 마이그레이션을 수행할 수 있습니다.

@RyanCavanaugh 여기에서 요구하는 모든 것은 다른 TypeScript 구문으로 구문적으로 처리할 수 있다고 언급했습니다.

mixin 제안에는 훨씬 더 많은 열린 질문이 있다고 생각합니다. 부분 클래스 제안은 TypeScript에서 이미 허용되는 일부 구문 설탕과 함께 코드화한 것입니다(이 기능은 문자 그대로 이미 가지고 있는 구문에 대한 구문 재매핑으로 수행될 수 있음).

그러면 TypeScript에서 이 작업을 수행하는 방법은 무엇입니까?:
파일1.ts:

// Imagine this file is code generated and could be regenerated during development
export partial class Contact
{
    firstName: string;
    lastName: string;
    partial OnInit( args: any ) : void;
    constuctor( args: any )
    {
        this.OnInit( args );
    }
}
export class Address
{
    addr: string;
    city: string;
    state: string;
    zip: string;
}

파일2.ts

// See where I'm going with this? This file would be hand edited and allows me to specify associations and children.
partial class Contact
{
    Addresses: string[] = [];
    partial OnInit( args: any ) void
    {
        this.firstName = args.firstName;
        this.lastName = args.lastName;
        this.Addresses.push( new Address() );
    }
}

위의 내용을 변환하면 다음과 같이 Contact에 대해 하나의 JS 클래스가 생성됩니다.

var Contact = (function () {
    function Contact() {
         this.Addresses = [];
   }
   Contact.prototype.constuctor = function (args) {
       this.OnInit( args );
   };
   Contact.prototype.OnInit = function (args) {
       this.firstName = args.firstName;
       this.lastName = args.lastName;
       this.Addresses.push(new Address());
   };
   return Contact;
})();

var Address = (function () {
    function Address() {
    }
    return Address;
})();

결국 나는 Contact라는 하나의 클래스를 원하고 두 개의 개별 클래스를 세 번째 클래스로 하위 클래스화하고 싶지 않습니다.

@cosmoKenney

다음은 작동하는 예제입니다. partial 만큼 구문적으로 과장되지는 않았지만 작동하고 매우 기능적인 솔루션입니다.

// address.ts
export class Address
{
    addr: string;
    city: string;
    state: string;
    zip: string;
}

// contact.impl.ts
import { Address } from './address';

// Class implementation, do the things here that are not code generated
export class Contact {
    firstName: string;
    lastName: string;
    addresses: Address[];
    constructor(args: any) {
        this.onInit(args);
    }
}
// extending the interface here
// define methods you know will need in the constructor only
// This only applies to the constructor however
export interface Contact {
    onInit(args: any): void;
}

// contact.partial.ts
import { Contact } from './contact.impl';

// Implement the extended contract here
Contact.prototype.onInit = function(this: Contact, args: any) {
    this.addresses = args.addresses.concat();
    // do stuff;
};

// Adding another method (not part of the extended interface)
Contact.prototype.somethingAwesome = function(this: Contact) {
    // do awesome stuff here
};

// Tell TypeScript "I added this here!!!!"
declare module './contact.impl' {
    interface Contact {
        somethingAwesome();
    }
}

// contact.ts
import { Contact } from './contact.impl';
import './contact.partial';

// Bring it all together (perhaps there are more than one partial class?)
export { Contact };

// main.ts
import { Contact } from './contact';

// use the contact!
const contact = new Contact(['my', 'args']);
const {firstName, lastName} = contact;
contact.somethingAwesome();

또는 코드에서 인터페이스를 생성하고 인터페이스 확장을 사용하여 구현할 수도 있습니다.

새로운 Mixin 기능을 사용하는 방법도 있을 수 있지만 아직 이에 대해 자세히 설명하지 않아 적절한 답변을 드릴 수 없습니다.

@david-driscoll 와우. 머리가 막 폭발했습니다.

커뮤니티가 문제를 해결하지 않고 부분 클래스를 단순히 지원하는 포크로 끝날지 궁금합니다.
지금까지 부분 클래스에 대한 실제 주장을 듣지 못했습니다. 게으름을 정당화하는 몇 가지 이유.

@greendimka

커뮤니티가 문제를 해결하지 않고 부분 클래스를 단순히 지원하는 포크로 끝날지 궁금합니다.
지금까지 부분 클래스에 대한 실제 주장을 듣지 못했습니다. 게으름을 정당화하는 몇 가지 이유.

여기서 무엇을 말하려는지 잘 모르겠습니다. 그러나 커뮤니티의 전반적인 느낌이 기존 언어 기능을 사용하여 동일한 결과를 얻을 수 있다는 것이라면 방법에 대한 몇 가지 예가 필요합니다. 위에 @david-driscoll이 게시한 내용은 내 이해를 훨씬 뛰어넘습니다. 그리고 문제를 완전히 해결하지 못하는 것 같습니다. 사실 내가 알 수 있는 바에 따르면 그는 내 의도를 잘못 해석했다.
내 주요 관심사는 코드가 pojo 또는 모델 클래스와 같은 클래스의 스칼라 속성을 생성하는 것입니다. 그러나 별도의 파일에서 또는 동일한 파일에서 할 수 있어야 하지만 기본 클래스 정의 내에서는 연결 속성을 추가할 수 없어야 합니다(이렇게 하면 새로 코드 생성된 기본 정의를 원본 위에 붙여넣을 수 있음).
예를 들어 위의 내 연락처 클래스는 firstName 및 lastName으로 생성된 코드를 가져옵니다. 그러나 별도의 정의에서 Address 개체 컬렉션의 정의 및 초기화를 추가합니다.
내 코드 생성기는 연결이 아닌 클래스의 속성만 알고 있으므로 david의 예에서와 같이 주소 컬렉션을 생성할 수 없습니다.

@cosmoKenney 주소가 어디에 있어야 하는지 완전히 명확하지 않았습니다. 문맥을 잘못 이해한 것을 용서하십시오. 나는 단지 대안을 제시하는 것을 도우려고 노력할 뿐입니다. 두 모듈 시스템(내부/외부)을 구현하는 데 많은 추가 고려 사항과 잠재적인 문제가 있는 부분 클래스와 같이 컴파일러에 무언가를 넣지 않고도 유사한 동작을 허용하는 기능이 많이 있습니다.

귀하의 경우 추상 기본 클래스를 생성하거나 인터페이스 생성이 작동하면 다른 클래스가 이를 상속합니다. 그러면 클래스가 생성되었다는 사실이 여전히 숨겨져 있습니다.

즉:

// address.partial.ts
export interface IAddress
{
    addr: string;
    city: string;
    state: string;
    zip: string;
}

// address.ts
import { IAddress } from './address.partial';

export class Address
{
    constructor(args: any) {

    }
}
export interface Address extends IAddress{}

// contact.partial.ts
import { IAddress } from './address.partial';

export interface IContact {
    firstName: string;
    lastName: string;
    addresses: IAddress[];
}

// contact.ts
import { Address } from './address';
import { IContact } from './contact.partial';

// Class implementation, do the things here that are not code generated
export class Contact {
    addresses: Address[] = [];

    constructor(args: any) {
        this.firstName = args.firstName;
        this.lastName = args.lastName;
        this.addresses.push( new Address("address?") );
    }

    public somethingAwesome() {
        //
    }
}
export interface Contact extends IContact {}

// main.ts
import { Contact } from './contact';

const contact = new Contact(['my', 'args']);
const {firstName, lastName} = contact;
contact.somethingAwesome();

@cosmoKenney : @david-driscoll은 흥미로운 솔루션을 제공하지만 여전히 실제 부분 클래스의 용이성이 부족합니다. 내 개인적인 실험에서 알 수 있듯이 개발자는 이러한 방식으로 만들어진 "부분"을 사용하지 않습니다. 이것은 좋은 해결 방법이지만 부분적인 작업의 용이함과 편안함은 없습니다.

현재 TypeScript 컴파일러가 내부적으로 어떻게 작동하는지 모르겠습니다. 나는 그것이 모든 소스 파일을 읽고 진행하고 JS 파일을 출력한다고 가정 할 수 있습니다. 그렇다면 - 여러 소스 파일에서 단일 클래스를 읽는 데 문제가 없습니다. 단일 클래스의 둘 이상의 소스 파일이 충돌하는 코드를 제공하는 경우(같은 속성이 두 번 정의됨) 컴파일러는 단순히 예외를 throw합니다. 구문상 유효하지 않은 코드를 작성하는 경우와 동일합니다.

@greendimka , @david-driscoll
위에서 David의 예를 컴파일하려고 시도했지만 ts는 그것을 좋아하지 않습니다.

C:\TestProjects\TypeScriptFakePartialClassTest>tsc -m amd address.partial.ts address.ts contact.partial.ts contact.ts main.ts
address.ts(4,14): error TS2300: Duplicate identifier 'Address'.
address.ts(10,18): error TS2300: Duplicate identifier 'Address'.
contact.ts(7,14): error TS2300: Duplicate identifier 'Contact'.
contact.ts(11,14): error TS2339: Property 'firstName' does not exist on type 'Contact'.
contact.ts(12,14): error TS2339: Property 'lastName' does not exist on type 'Contact'.
contact.ts(20,18): error TS2300: Duplicate identifier 'Contact'.
main.ts(5,8): error TS2459: Type 'Contact' has no property 'firstName' and no string index signature.
main.ts(5,19): error TS2459: Type 'Contact' has no property 'lastName' and no string index signature.

게다가 나는 이것이 대규모 애플리케이션에서 수백 번 사용하기에는 너무 복잡하다는 @greendimka의 말에 동의합니다.

@greendimka 컴파일러가 어떻게 작동하는지 모르지만 작업을 과소 평가하지 마십시오. JavaScript는 .NET이 아니며 모듈은 전역적으로 사용할 수 없습니다(말 그대로 가져와야 함).

구현되는 것을 보고 싶지만 이 작업은 다음과 같이 신중하게 생각해야 할 몇 가지 사항을 제공합니다.

• 파일 A에 클래스의 일부를 정의하고 파일 B에 일부를 정의하는 경우 트랜파일 후 전체 클래스를 포함해야 하는 파일은 무엇입니까? 새로운 것을 생성해야 합니까?
• 부분적인 내용을 포함하는 모든 파일이 동일한 클래스를 내보내야 합니까?
• 추가 파일에 기본 파일이 필요한 경우 순환 종속성을 피하는 방법은 무엇입니까?
• 클래스 자체보다 모듈에서 더 많은 것을 내보내면 어떻게 됩니까?
• 이름 충돌 확인?

등등...

@greendimka 아래 내 응답을 참조하십시오. (편집: @WoLfulus를 대상으로

파일 A에 클래스의 일부를 정의하고 파일 B에 일부를 정의하는 경우 트랜파일 후 전체 클래스를 포함해야 하는 파일은 무엇입니까? 새로운 것을 생성해야 합니까?

파일 A.js에 전체 정의가 있고 파일 B에 스텁이 있으면 정말 기쁠 것입니다. 미리 준비된 댓글이 있을 수 있습니다. 우리 대부분은 어쨌든 번들로 묶이기 때문에 번들로 제공되는 무수한 .js 파일은 결국 본질적으로 나중에 생각하게 됩니다.

부분적인 내용을 포함하는 모든 파일이 동일한 클래스를 내보내야 합니까?

이것은 첫 번째 질문에 대한 나의 답변으로 거의 답이 되었습니다.

추가 파일에 기본 파일이 필요한 경우 순환 종속성을 피하는 방법은 무엇입니까?

모르겠어요. 이 시나리오를 인식하는 것이 모듈 로더의 역할이 아닙니까?

클래스 자체보다 모듈에서 더 많은 것을 내보내면 어떻게 됩니까?

나는 이것에 문제가 있다고 생각하지 않는다. 즉, B.ts에 부분 정의와 일부 다른 비-부분 클래스가 모두 있는 경우 B.js에는 위에서 언급한 미리 준비된 주석과 비-부분 클래스의 정의가 포함되어야 합니다. 간단하다고 생각합니다.

이름 충돌 확인?

어떻게 이름 충돌로 끝날까요? 클래스를 의미하는 경우 "부분"키워드가이를 해결합니다. 그러나 두 개의 다른 파일이 모두 동일한 이름을 가진 클래스를 정의했지만 "partial" 키워드가 없는 경우 컴파일러는 중복 유형에 대한 오류를 내보내야 합니다. 그러나 동일한 이름의 속성이나 메서드를 정의하는 동일한 클래스의 두 부분 정의에 대해 이야기하는 경우 컴파일러는 현재와 같이 중복 멤버에 대한 오류를 내보내야 합니다.

@WoLfulus , @cosmoKenney님 이 답변을

@cosmoKenney

추가 파일에 기본 파일이 필요한 경우 순환 종속성을 피하는 방법은 무엇입니까?
모르겠어요. 이 시나리오를 인식하는 것이 모듈 로더의 역할이 아닙니까?

TypeScript에는 모듈 로더가 없습니다.

@greendimka

커뮤니티가 문제를 해결하지 않고 부분 클래스를 단순히 지원하는 포크로 끝날지 궁금합니다.
지금까지 부분 클래스에 대한 실제 주장을 듣지 못했습니다. 게으름을 정당화하는 몇 가지 이유.

좋은 생각이 아닙니다. 예를 들어, 동적 가져오기가 추가될 때 포크를 어떻게 유지 관리할 것인지 생각해 보셨습니까?
또한 부분 클래스에 대해 많은 주장이 제기되었습니다. TypeScript와 JavaScript 파일 간의 소스 대 소스 대응 관계를 깨는 것은 언어의 핵심 교리에 어긋납니다. 기능이 부분 클래스보다 훨씬 더 가치 있는 시나리오를 가능하게 하는 기능이 필요하다고 생각합니다. 여전히 거부될 가능성이 높습니다.

@WoLfulus , @cosmoKenney님 이 답변을

나는 당신이 당신의 메시지를 전달하고 있다고 생각하지 않습니다. 그것은 마치 어떤 언어로든 자신을 표현하는 데 직면하는 모든 제한이 완전히 임의적인 이유로 존재한다고 느끼는 것처럼 들립니다.
또한 @WoLfulus '질문에 대한 답변이 없었습니다. 적어도 제 만족은 아닙니다.

돈스 플레임슈트

TL;DR: 이것은 일어나지 않습니다. 여기 댓글 번호 189에 있고 이에 대한 비승인을 등록하려면 먼저 전체 스레드를 읽으십시오. 이 항목을 추가하지 않는 좋은 이유는 위에서 광범위하게 다루었기 때문입니다.

이 상황에 대한 우리의 해석은 다음과 같습니다.

• TypeScript에는 "ES6 + 유형"으로 의도된 것에 대해 이미 너무 많은 TS 관련 클래스 기능(생성자 속성 선언, 멤버 이니셜라이저, 미완성 데코레이터, 액세스 수정자, implements 등)이 있습니다. . 그 중 일부는 우리의 잘못이고(우리의 원래 디자인 방향은 일반적으로 너무 OOP였습니다) 그 중 일부는 ES6의 잘못입니다(5년 전에 클래스 제안 이 많이 이동했고 결국에는 충족하지 못한 기능을 갖게 되었습니다). 또 다른 TS 특정 클래스 기능을 추가하는 것은 우리가 할 수 있는 한 피해야 하는 낙타 등의 또 다른 빨대입니다.
• 분명히 JavaScript의 미래는 모듈입니다. 부분 클래스는 "글로벌 수프" 모델에서만 의미가 있고 잘 작동합니다. 여러 모듈에 걸쳐 부분 클래스를 허용하는 것은 로드 순서를 예측할 수 없기 때문에 재앙을 초래합니다. 전역 전용 유니버스에서만 잘 작동하는 기능을 추가하는 것은 시간을 잘 활용하지 못합니다.
• C#이 가지고 있지만 우리는 C#을 재발명하기 위해 여기에 있는 것이 아닙니다. 진지하게!
• "생성된 코드" 시나리오는 장점에 대해 설득력이 없습니다. 부분 클래스에 대한 그럴듯한 방출은 속성 이니셜라이저와 생성자 코드를 정확히 하나의 선언으로 제한하며 사용자 코드와 생성된 코드 모두 이니셜라이저 또는 생성자 논리가 필요할 수 있으므로 .Designer.cs 스타일 설정에 대한 딜 브레이커가 됩니다. .
• JS에서 사용할 수 있는 다른 많은 구성 메커니즘(mixins, Object.assign 등)이 있습니다. C#에서 이 기능을 제공하는 시나리오는 단순히 JS에는 없는 제약 조건에 의해 주도되었습니다.
• 현재 해결 interface + prototype.method = ... 단지뿐만 아니라 생성 된 코드 시나리오를 가능하게 않습니다 partial class 것. 그 코드를 손으로 작성하는 것은 이상하지만 코드를 다르게 생성하는 데는 문제가 없습니다. 따라서 분할 파일 생성 코드 설정이 문제를 해결하는 유일한 방법이라고 정말로 생각한다면(나는 회의적입니다) 그 방법을 사용할 수 있습니다 .
• 우리는 ES6이 수업을 위한 "필수품"의 중재자라고 생각합니다. TypeScript는 형식이 지정되지 않은 JavaScript보다 부분 클래스가 필요하다는 C# 프로그래머의 매력을 제외하고는 특별한 것이 없습니다. 따라서 부분 클래스를 추가하기 위해 실제로 그것을 공원 밖으로 두드리는 시나리오가 있다면 그 시나리오는 TC39 프로세스를 통해 스스로를 정당화할 수 있어야 합니다. 그것이 견인력을 얻는다면 우리는 그것에 대한 입력으로 무게를 다는 것을 기쁘게 생각하지만 이것은 누구의 레이더에도 없는 것 같습니다.

이에 대해

interface + prototype.method = ...의 현재 해결 방법은 부분 클래스와 마찬가지로 생성된 코드 시나리오를 활성화합니다.

내가 한 번 이상 언급했듯이, 내가 필요한 것을 달성하는 데 부분적이지 않고 C#이 아닌 방법이 있는 것은 괜찮습니다. 작업 예제를 요청하면 됩니다. david-driscoll은 매우 도움이 되었지만 컴파일되지 않는 코드를 게시했습니다. 따라서 예를 들어 위와 같이 이름, 성에 대해서만 스칼라 속성이 있는 클래스를 코드로 생성할 수 있다고 생각한다면 괜찮습니다. 다른 유형의 컬렉션을 직접 코딩하여 클래스의 속성으로 추가하는 방법이 필요합니다. 하지만 그 세트의 초기화를 처리하는 방법도 필요합니다.

@cosmoKenney 올바른 코드를 복사한 사이트입니까? 두 번째 예제에는 동일한 클래스 이름 대신 인터페이스가 있습니다. 원하는 경우 코드의 Zip을 첨부할 수 있습니다. 인터넷상의 임의의 파일이 나쁠 수 있고 내가 악의적인 것을 게시하고 있다고 생각하기를 원하지 않았기 때문에 나는 주저했습니다 🙂

유감스럽게도 여기에서 내린 디자인 결정을 존중합니다. 괜찮으시다면 몇 가지 질문이 있습니다.

TypeScript에는 "ES6 + 유형"으로 의도된 것에 대해 이미 너무 많은 TS 관련 클래스 기능(생성자 속성 선언, 멤버 이니셜라이저, 미완성 데코레이터, 액세스 수정자, 구현 등)이 있습니다. 그 중 일부는 우리의 잘못이고(우리의 원래 디자인 방향은 일반적으로 너무 OOP였습니다) 그 중 일부는 ES6의 잘못입니다(5년 전에 클래스 제안이 많이 이동했고 결국에는 충족하지 못한 기능을 갖게 되었습니다). 또 다른 TS 특정 클래스 기능을 추가하는 것은 우리가 할 수 있는 한 피해야 하는 낙타 등의 또 다른 빨대입니다.

이를 고려할 때 JS의 순수한 유형과 TS가 제공하는 다른 언어 구성을 조직적으로 코드적으로 명확하게 구별할 수 있는 방법이 있을까요? 나는 타이핑 과 추가 언어 기능을 모두 좋아합니다. 소비자/개발자로서 나는 TS가 JS에 없는 것들을 추가한다는 사실에 대해 별로 신경 쓰지 않습니다. TC39가 원하지 않는다면 저에게 멋진 것을 주십시오. 저는 상관하지 않습니다.

TS가 이러한 것들을 서로 캡슐화한다면 대체하기보다는 SoundScript와 같은 프로젝트에서 재사용하고 분기하고 구축하는 것이 더 쉬울까요?

그리고 다른 프로젝트는 이 타이핑을 기반으로 JS가 제공하는 것보다 더 나은/다른 언어 구성을 제공할 수 있습니다.

분명히 JavaScript의 미래는 모듈입니다. 부분 클래스는 "글로벌 수프" 모델에서만 의미가 있고 잘 작동합니다. 여러 모듈에 걸쳐 부분 클래스를 허용하는 것은 로드 순서를 예측할 수 없기 때문에 재앙을 초래합니다. 전역 전용 유니버스에서만 잘 작동하는 기능을 추가하는 것은 시간을 잘 활용하지 못합니다.

진짜야? 모듈이 JavaScript의 자연스러운 부분이 되겠지만, 코드의 원래 본문은 어떻습니까? 나는 namspaces를 좋아하며 제대로 수행되면 수프가 없습니다. 나는 그것을 하나의 파일로 컴파일하고 있으며 모듈 로더가 필요하지 않으며 거의 ​​모든 경우에 비동기 모듈 로딩이 필요하지 않습니다. https://github.com/Microsoft/TypeScript/issues/420 과 같이 제안된 일부 항목은 네임스페이스에서만 가능하고 관련이 있습니다. 모듈만 사용해야 하기 때문에 이런 일이 일어나지 않는다는 말씀이신가요? 네임스페이스가 지원 중단의 길에 있습니까?

@david-driscoll 감사합니다. 이미 충분히 도움이 되셨습니다. @RyanCavanaugh 는 문제를 계속 닫고 해결 방법이 있다고 말하는 사람이므로 해결 방법의 예를 제공해야 합니다.

또한 부분 클래스가 무엇인지에 대한 많은 오해를 보고 있습니다. 그것은 정말 간단한 구성이며 모든 사람들이 이것을 과도하게 부풀리고 있습니다.
https://msdn.microsoft.com/en-us/library/wa80x488.aspx

이를 고려할 때 JS의 순수한 유형과 TS가 제공하는 다른 언어 구성을 조직적으로 코드적으로 명확하게 구별할 수 있는 방법이 있을까요? 나는 타이핑과 추가 언어 기능을 모두 좋아합니다. 소비자/개발자로서 나는 TS가 JS에 없는 것들을 추가한다는 사실에 대해 별로 신경 쓰지 않습니다. TC39가 원하지 않는다면 저에게 멋진 것을 주십시오. 저는 상관하지 않습니다.

그것은 언어를 다시 작성하고 모든 사람의 코드를 깨는 것입니다.

또한 "멋진 걸 줘"라는 것은 TypeScript 의 CoffeeScript , Dart 또는 Haxe 와 같은 다른 언어를 선택해야 합니다. 물론 TypeScript 채택이 잘 되지 않는 데에는 이유가 있을 수 있습니다.

문제를 계속 닫고 해결 방법이 있다고 말하는 사람은 해결 방법의 예를 제공해야 합니다.

partial 해결하는 것에 대한 많은 사용 사례가 있습니다. 거의 모든 언어 구성에는 유효한 사용 사례가 많지만 적절한 이유로 선택하고 선택해야 합니다.

"나는 친환경 자동차를 원합니다"와 같이 특정 언어 기능을 계속 요구하지만 문제의 핵심에 도달하지 못합니다. 왜 자동차가 친환경이어야 합니까? 자동차가 녹색이어야 하는 이유를 설명하거나 실제 요구 사항을 충족하는 한 자동차 색상에 실제로 관심이 없다는 사실에 대해 개방적입니다.

정당한 이유 때문에 자동차 회사가 친환경 자동차를 생산하지 않기로 결정했기 때문에 자동차를 다시 칠하는 방법을 알려주는 것이 Ryan의 의무라고 느끼는 이유를 모르겠습니다.

(아 그리고 TypeScript 2.2에 추가된 믹스인 클래스는 내가 생각하기에 실제 필요하다고 생각되는 것을 달성하는 좋은 방법입니다)

interface Base {}

interface Constructor<T> {
    new (...args: any[]): T;
    prototype: T;
}

interface PartialClass {
    foo(): void;
}

function PartialClass<B extends Constructor<Base>>(base: B): B & Constructor<PartialClass> {
    return class extends base {
        foo() {
            console.log('foo');
        }
    };
}

class MyBase {
    bar() {
        console.log('bar');
    }
}

const MyPartialBase = PartialClass(MyBase);

const instance = new MyPartialBase();

instance.bar();
instance.foo();

@kitsonk 믹스인은 같은 것이 아닙니다.

• Mixin은 기존 클래스에 추가할 수 있는 자체 포함된 단위입니다.
• Partial 클래스는 마치 같은 클래스의 일부인 것처럼 다른 partial의 멤버에 액세스할 수 있습니다.

연습으로 믹스인을 사용하여 다음 코드 분할을 구현해 보세요.

partial class Point {
  readonly x: number;
  readonly y: number;
}

partial class Point {
  translate(dx: number, dy: number): Point {
    return new Point(this.x + dx, this.y + dy);
  }
}

연습으로 다음 코드 분할을 믹스인으로 구현해 보세요.

다시 요점으로 돌아가서... 언어 기능을 지적하는 대신 예제에서 해결하려는 문제는 무엇입니까? TypeScript의 해결 방법은 쉽기 때문에:

class Point {
  readonly x: number;
  readonly y: number;
  translate(dx: number, dy: number): Point {
    return new Point(this.x + dx, this.y + dy);
  }
}

(그리고 우리가 완전하지만 모든 사용 사례가 아닌 사용을 해결 하는 경우)

interface PointBase {
    x: number;
    y: number;
}

interface Constructor<T> {
    new (...args: any[]): T;
    prototype: T;
}

interface TranslatePointPartial {
    translate(dx: number, dy: number): TranslatePointPartial;
}

function TranslatePointPartial<B extends Constructor<PointBase>>(base: B): B & Constructor<TranslatePointPartial> {
    return class TranslatePointPartial extends base {
        translate(dx: number, dy: number): TranslatePointPartial & PointBase {
            return new TranslatePointPartial(this.x + dx, this.y + dy);
        }
    };
}

class Point {
    readonly x: number;
    readonly y: number;
}

const MyPoint = TranslatePointPartial(Point);

const instance = new MyPoint();

instance.x;
instance.y;
instance.translate(1, 2);

@코끼리 배

이를 고려할 때 JS의 순수한 유형과 TS가 제공하는 다른 언어 구성을 조직적으로 코드적으로 명확하게 구별할 수 있는 방법이 있을까요?

이 시점에서 둘을 분리할 방법이 보이지 않습니다. 이론적으로 TypeScript로 구문적으로 변환된 CoffeeScript 언어를 작성하고 이 고급 언어를 사용하여 TS의 유형 시스템을 계속 사용하면서 새로운 구문 기능을 추가할 수 있지만 여기까지는 가능합니다. 다른 많은 미개발 환경에서 JS로 컴파일하는 언어 중 하나를 선택하는 것이 목표라면 더 나은 선택인 것 같습니다.

모듈만 사용해야 하기 때문에 이런 일이 일어나지 않는다는 말씀이신가요? 네임스페이스가 지원 중단의 길에 있습니까?

네임스페이스는 확실히 아무데도 가지 않습니다. 그것들은 이미 널리 사용되는 패턴의 이름일 뿐이며 ES6 모듈의 세계에서 여전히 충분히 의미가 있습니다. 모듈은 사람들이 코드를 구성하는 방식이 점점 더 늘어나고 있으며 많은 이점이 있습니다. 나는 단지 부분 클래스가 그 세계에서 거의 의미가 없으며, 그것과 호환되지 않는 근본적으로 새로운 조직 패턴을 추가하는 것이 이상할 것이라고 말하는 것입니다. 세상이 반대 방향으로 움직이고 있고 모두가 "부작용이 있는 글로벌 스크립트는 굉장하고, 모두가 서로의 prototype s에 파티를 맺는다"라고 한다면 아마 우리는 다르게 느낄 것입니다.

@RyanCavanaugh

아마도 그렇게 ... 아마도 그들은 그다지 의미가 없을 것입니다 ... 그러나 내가 여러 번 말했듯이 이 스레드에서도 부분 클래스는 코드 생성을 더 쉽게 만드는 것입니다 ... 이것이 내가 보는 주요 이점입니다. 그들로부터 TS의 기능의 가치가 있습니다... 저와 저는 다른 많은 사람들을 가정해야 하지만 그것은 단지 추측일 뿐입니다. 현재 내 C# 코드에서 수많은 TS 코드를 생성하고 있습니다... 그러나 문제는 생성된 TS 코드??? 이것은 부분 클래스로 대답하기 훨씬 쉬운 질문입니다... 현재 우리는 생성된 TS 코드 파일에 사용자 정의 코드를 유지하기 위해 해킹에 의존하고 있습니다...

감사 해요

여기에서도 마찬가지로 C# API에 대한 typescript "proxy"를 생성하고 이러한 개체를 typescript에서 쉽게 확장할 수 있기를 원합니다.

저는 JS 전문가가 아니므로 누락된 것이 있어야 합니다. 여러 TS 파일에서 클래스 선언을 분할할 수 있는 이유를 알지 못하기 때문입니다(컴파일 후 하나의 JS 파일에서만 하나의 클래스 선언만 사용). JS 세계의 문제. 내가 보기에는 마치 처음부터 하나의 파일에 작성된 것처럼 JS의 경우 투명합니다. 내 말은, 부분 클래스를 사용하든 사용하지 않든 JS 출력은 정확히 동일하지만 개발자의 JS 개체 확장 비용을 방지할 것입니다.

@RyanCavanaugh

개인적으로 언급하고 싶은 또 한 가지는 다른 TS 파일의 부분 클래스를 사용하여 ES6 모듈을 생성할 때 발생할 수 있는 패키징 딜레마를 TS 컴파일러에게 어떻게든 해결하도록 요청하지 않는다는 것입니다. 여러 TS 파일을 ES6 모듈용 단일 js 파일로 컴파일... 다시 말하지만, 부분 클래스는 코드 생성에 크게 도움이 됩니다... 도구를 사용하면 신뢰할 수 있는 확장성과 함께 모델의 큰 부분을 생성할 수 있습니다...

@kitsonk

"나는 친환경 자동차를 원합니다"와 같이 특정 언어 기능을 계속 요구하지만 문제의 핵심에 도달하지 못합니다. 왜 자동차가 친환경이어야 합니까? 자동차가 녹색이어야 하는 이유를 설명하거나 실제 요구 사항을 충족하는 한 자동차 색상에 실제로 관심이 없다는 사실에 대해 개방적입니다.

아니요, 더 이상 새로운 기능을 요구하지 않습니다. 언어가 내가 원하는 것을 성취할 수 있다는 것은 반복해서 언급되어 왔습니다. 내가 원하는 것(C#에서)에 대한 예를 제공했지만 유용한 예에서 내가 있어야 할 위치에 도달하는 방법을 아직 보지 못했습니다.

정당한 이유 때문에 자동차 회사가 친환경 자동차를 생산하지 않기로 결정했기 때문에 자동차를 다시 칠하는 방법을 알려주는 것이 Ryan의 의무라고 느끼는 이유를 모르겠습니다.

Ryan은 여기에서 중재자인 것으로 보이며 문제를 종료합니다. 그렇기 때문에. 그가 언어 권위자라면 아마도 내 필요를 이해하기 위해 노력하고 모국어 기능으로 수행하는 방법에 대한 예를 제공하지 않고 이 요청을 무시하기 전에 문제를 종료해서는 안 됩니다. 나는 컴파일 타임 솔루션을 원한다고 말했습니다. 그리고 저는 꽤 좋은 개발자이며 여러 가지 다른 모호한 언어로 프로그래밍을 하고 있는데도 여전히 mixin 구문에 어려움을 겪고 있습니다. 그 복잡하고 이해하기 어려운 것이 어떻게 언어에 들어왔는지 이해하지 못하지만 C#에서 차용했기 때문에 모든 사람들이 부분 클래스 구문의 우아함을 거부하고 있는 것 같습니다.

Ryan은 여기에서 중재자인 것으로 보이며 문제를 종료합니다. 그렇기 때문에. 그가 언어 권위자라면 아마도 내 필요를 이해하기 위해 노력하기 전에 문제를 닫지 말아야 할 것입니다.

🤔

@RyanCavanaugh , 나는 당신이 돕기 위해 노력했다는 것을 알고 있습니다. 그리고 이 시점에서 믹스인을 시도하려고 합니다. 아니면 그냥 상속, 아니면 이 프로젝트를 완료하는 데 너무 급해서 제네릭으로 이 작업을 수행하는 방법을 간과하고 있습니다. 흠...
상속 및 이름 지정을 통해 다음을 수행할 수 있습니다.

class AddressBase // this is a code generated class
{
    public address: string;
    public city: string;
    public state: string;
    public zip: string;

    constructor( jsonFromService: any )
    {
        this.OnInit( jsonFromService );
    }

    OnInit( jsonFromService: any )
    {
        // could use Object.assign here
        this.address = jsonFromService.address;
        this.city = jsonFromService.city;
        this.state = jsonFromService.state;
        this.zip = jsonFromService.zip;
    }
}

class ContactBase // this is also a code generated class
{
    public firstName: string;
    public lastName: string;

    constructor( jsonFromService: any )
    {
        this.OnInit( jsonFromService );
    }

    OnInit( jsonFromService: any )
    {
        // could use Object.assign here
        this.firstName = jsonFromService.firstName;
        this.lastName = jsonFromService.lastName;
    }
}

// classes that extend the functionality of the code generated classes:
class Address extends AddressBase // subclass simply because I don't want to have to use AddressBase all over my codebase, and then refactor if I ever extend the class
{
}

class Contact extends ContactBase
{
    public Addresses: Address[] = []; // THIS is the customization/extension that cannot be code generated.

    OnInit( jsonFromService: any )
    {
        // note that jsonFromService receives a dto with a array of address info
        super.OnInit( jsonFromService );

        for ( let addr of jsonFromService.Addresses )
        {
            this.Addresses.push( new Address( addr ) );
        }
    }
}

그리고 그것은 나를 위해 잘 작동합니다. 그것은 예쁘지 않으며 코드에서 사용하고 싶지 않은 이름을 내 코드 생성 클래스에 강제로 적용합니다. 그러나 다시 작동합니다.

현재 부분계급을 강력하게 반대하는 남성들은 부분계급의 개념을 잘못 이해하고 있는 것 같고, 부분계급은 부분계급이 아닌 것으로 생각하는 것 같습니다.

명확히 하자면, 부분 클래스는 동일한 단일 클래스의 정의를 여러 물리적 파일로 분할할 수 있는 구문 구조입니다. 여기서 키워드는 "동일" 및 "단일"입니다.

TypeScript의 문서는 부분 클래스에 대한 잘못된 정의를 제공합니다(여기의 첫 번째 단락: https://www.typescriptlang.org/docs/handbook/mixins.html ).

실제 부분 클래스 개념의 예:

"Point.generated.ts" 파일:

partial class Point {
   readonly x: number;
   readonly y: number;
}

파일 "Point.codeByHand.ts":

partial class Point {
  constructor(x: number, y: number) {
      this.x = x;
      this.y = y;
  }

  translate(dx: number, dy: number): Point 
  {
      return new Point(this.x + dx, this.y + dy);
  }
}

"Point.js"로 컴파일되며 이름은 파일 이름이 아닌 클래스 이름에서 나옵니다.

var Point = (function () {
    function Point(x, y) {
        this.x = x;
        this.y = y;
    }
    Point.prototype.translate = function (dx, dy) {
        return new Point(this.x + dx, this.y + dy);
    };
    return Point;
}());

Mixins는 "부분 클래스"로 사용될 때(문서에서 이 용어가 잘못 사용 되었다고 강력하게 믿습니다) 실제로 다중 상속( https://en.wikipedia.org/wiki/Multiple_inheritance )을 나타냅니다.

따라서 우리는 실제 부분 클래스와 다중 상속이라는 두 가지 다른 도구에 대해 논의합니다. 이들은 두 가지 다른 도구입니다. 그리고 모든 도구와 마찬가지로 고유한 적용 영역이 있습니다. 다시 말해, 목수는 망치를 사용할 수 없지만 망치가 올바른 도구가 아닐 때 망치 대신 망치를 사용할 수 있습니다.

IMHO, 이 토론에는 미래가 없으며 중단해야 합니다. 실제 부분 클래스에 대한 기술적인 문제는 아직 보이지 않지만 팀은 적어도 현재로서는 이를 구현하고 싶지 않습니다.

TS 팀은 가능하면 TS 관련 기능을 구현하고 싶지 않습니다. 더 논의하고 싶다면 여기가 더 좋습니다: https://esdiscuss.org/topic/class-syntax-enhancements

TC39 측 에 GitHub repo가 ​​있기를 바랍니다. 메일링을 기반으로 하는 것보다 이 문제를 논의할 수 있습니다

@greendimka

현재 부분계급을 강력하게 반대하는 남성들은 부분계급의 개념을 잘못 이해하고 있는 것 같고, 부분계급은 부분계급이 아닌 것으로 생각하는 것 같습니다.

명확히 하자면, 부분 클래스는 동일한 단일 클래스의 정의를 여러 물리적 파일로 분할할 수 있는 구문 구조입니다. 여기서 키워드는 "동일" 및 "단일"입니다.

여기 있는 누구도 부분 클래스의 정의를 오해하고 있다고 생각하지 않습니다. 아마도 JavaScript의 클래스 정의를 오해하고 있는 것 같습니다.

JavaScript 클래스가 널리 사용되는 거의 모든 다른 언어에서 볼 수 있는 클래스와 전혀 비슷하다는 인상을 받고 있다면 다른 사람들이 오해하고 있다는 것이 _나타나는__ 것입니다.

그러나 이 토론에서 여러 번 말했듯이 적어도 한 번은 명시적으로 말했듯이 JavaScript 클래스는 선언적 구성이 아니라 필수입니다.

명령문이 실행될 때까지 존재하지 않습니다.

그것들을 정의하는 것은 돌연변이에 의존합니다.

이것은 상속과 관련하여 이미 부서지기 쉽고 순서에 의존하게 만듭니다.

이 계속 될 수 있습니다 ...

@cosmoKenney

그 복잡하고 이해하기 어려운 것이 어떻게 언어에 들어왔는지 이해하지 못하지만 C#에서 차용했기 때문에 모든 사람들이 부분 클래스 구문의 우아함을 거부하고 있는 것 같습니다.

정말 옳지 않다고 생각합니다. Java 프로그래머 😛를 비롯한 모든 사람이 C#을 사랑하고 TypeScript는 다르다고 해서 다르지 않습니다.

@aluanhaddad

JavaScript의 클래스 정의를 잘못 이해하고 계신 것 같습니다...

인용 및 이하: TypeScript에 대해 이야기하고 있습니다.
내가 말했듯이: JavaScript의 구성으로 컴파일될 TypeScript에서 실제 부분 클래스를 구현하는 기술적인 문제는 없습니다.

@greendimka

인용 및 이하: TypeScript에 대해 이야기하고 있습니다.
내가 말했듯이: JavaScript의 구성으로 컴파일될 TypeScript에서 실제 부분 클래스를 구현하는 기술적인 문제는 없습니다.

이 만족의 문제는 TypeScript 클래스와 같은 것이 없습니다.

오 소년! 어떤 사람들은 이유를 무엇이든 사용할 것입니다.
좋아, TypeScript에는 클래스가 없습니다. 또는 TypeScript 클래스. 또는 무엇이든. 무엇이든.

나는 그들이 JavaScript 클래스라는 것을 의미합니다. 내가 현학적이라는 죄책감이 들기도 하지만, 클래스에 추가하기 쉬운 기능을 논의하기 전에 클래스라는 용어의 정의에 동의해야 하기 때문에 이 구분을 매우 구체적으로 하고 있습니다.

나는 우리가 수업에 대해 말할 때 같은 것을 의미하지 않는다고 생각합니다. 그것은 인지 부조화를 일으키고 상호 이해를 방해합니다.

우리가 수업에 대해 말할 때 같은 것을 의미하지 않는 것 같아요. 인지 부조화를 일으키고 상호 이해를 방해합니다..
전적으로 동의합니다!

실제로 이 주제의 첫 번째 게시물은 요청된 내용을 완벽하게 설명하므로 이 토론에는 미래가 없습니다. :)

@greendimka 예, TypeScript에 부분 클래스가 없을 것 같기 때문에 미래가 없습니다. 제 생각에는 좋은 일입니다.

하지만 오해와 오해는 좋은 게 아니라서 아직도 너와 대화를 하고 있다.

불행히도, 당신은 어느 쪽에도 관심이 없는 것 같습니다

A. JavaScript가 클래스라는 것을 설명하면 마음이 바뀌고 쉽게 부분화될 수 있다는 데 동의할 수 있습니다.

B. JavaScript 클래스가 무엇인지 다른 사람에게서 배우기 때문에 반대되는 관점을 이해해야 합니다.

나는 이것이 부끄러운 일이라고 생각하지만 당신이 원한다면 더 이상 논의하지 않겠습니다.

나는 어떤 토론에도 반대하지 않습니다. 그러나 부분 클래스는 구현되지 않을 것이라고 여기에서 여러 번 언급되었습니다(적어도 지금은 아님). 그래서 다른 일에 집중하는 게 좋을 것 같아요. 아마도 TypeScript는 미래에 변경될 수 있습니다. 누가 알겠습니까?
A와 B와 관련하여. 나는 JavaScript를 싫어합니다. 그러나 나는 그것을 아주 잘 알고 있으며 물론 클래스가 어떻게 "표현"되는지 알고 있습니다. 그러나 이 전체 토론의 요점은 JavaScript를 수정하는 것이 아니라 "낮은 수준" JavaScript 코드를 생성하는 상위 언어인 TypeScript의 기능을 개선하는 것입니다.
TypeScript를 C++로, JavaScript를 기계어 코드로 대체한다고 상상해 보십시오. 기계 코드에는 C++에 존재하는 대부분의 개념이 없습니다. 그러나 C++는 그것 때문에 진화를 멈춰야 합니까? 물론 아닙니다. 일부 오래된 컴파일러는 컴파일할 수 없기 때문에 개발을 중단해야 합니까? 물론 아닙니다. 개발자에게 새로운 기능을 제공하고 새로운 컴파일러와 함께 작동한다고 말합니다. 사용 여부는 개발자가 결정합니다.

@aluanhaddad
맨 오 맨. 누가 방정식의 Javascript 부분에 신경을 쓰나요? TypeScript는 위의 레이어이거나 원하는 문구입니다. 이전 4GL 대 3GL 토론을 기억하십니까? TypeScript는 4GL이 3GL인 것처럼 JavaScript에 대한 것입니다. 또한 TypeScript가 강력한 유형의 ES6이므로 Partial Classes가 TypeScript의 로드맵 범위를 벗어났다는 주장은 LAME입니다. Mixins, Generics, Modules, Name Spaces 및 Type Casting이 있습니다. 그렇다면 Partial Classes로 더 많은 노력을 기울이지 않겠습니까?

부분 클래스에서 원하는 것은 단일 TypeScript 클래스의 모든 다양한 정의를 하나의 최종 - 낮은 수준 - 3GL - Javascript 클래스 정의로 병합할 수 있게 해주는 구문 설탕입니다. 최종 JavaScript 클래스 정의에는 영향이 없어야 합니다. 맞죠? Javascript로의 변환의 최종 제품이 이 토론의 일부인 이유는 무엇입니까? 진지하게.

@cosmoKenney "유형이 있는 Scala.js 를 사용해 보세요.

편집: 방금 ES.next에서 부분 클래스가 사용자 정의 모듈 로더로 구현될 수 있다는 흥미로운 사실을 깨달았습니다. 사용하는 경우

import {MyClass} from './myclass.*'

로더는 와일드카드와 일치하는 모든 파일에서 내보낸 모든 MyClass 정의를 단일 클래스로 병합한 다음 제공할 수 있습니다.

@spion 나는 당신이 그것들을 ES.next 부분 클래스로 아주 ​​정확하게 언급하는 방식을 좋아합니다. 브라우저와 같은 ES 모듈 로더 또는 SystemJS와 같은 로더 폴리필은 부분 클래스를 지원합니다.
TypeScript 수준에서 이 기능을 추가할 때 발생하는 주요 문제 중 하나는 로더 및 패키지 도구와 같은 기존 도구가 손상된다는 것입니다. 반면에 ECMAScript에서 지정했다면 이러한 모든 도구는 기능을 구현하고 TypeScript는 이러한 모든 도구와 계속 호환됩니다.

Scala.js에 대해 확실히 동의합니다.

@cosmoKenney

Mixins, Generics, Modules, Name Spaces 및 Type Casting이 있습니다. 그렇다면 Partial Classes로 더 많은 노력을 기울이지 않겠습니까?

TypeScript에서 볼 수 있는 믹스인은 TypeScript _types_인 ECMAScript 디자인 패턴입니다.

제네릭은 유형 시스템 기능이므로 적용되지 않습니다.

모듈은 ECMAScript 기능입니다.

네임스페이스는 ECMAScript 디자인 패턴을 위한 구문적 설탕이자 형식화입니다.

타입 캐스팅은 TypeScript에 존재하지 않습니다.

@aluanhaddad 왜 이것을 런타임으로 계속 만들고 있습니까? 모듈 로더 및 트랜스파일과 관련이 없는 모든 것.

+1

@cosmoKenney

@aluanhaddad 왜 이것을 런타임으로 계속 만들고 있습니까? 모듈 로더 및 트랜스파일과 관련이 없는 모든 것.

그것은 옳지 않다.

SystemJS 및 Webpack 에코시스템을 살펴보면 그렇지 않은 것을 볼 수 있습니다.

훨씬 더 전통적이고 견고한 gulp 워크플로우는 입력 파일과 출력 파일 간의 대응에 의존합니다.

+1

도구를 사용하여 대부분의 기본 클래스를 생성하기 때문에 부분 클래스가 필요합니다(모델에 변경 사항이 있을 때 자동화하기 위해). 그런 다음 부분 클래스를 사용하여 별도의 파일에 있는 클래스에 기능을 추가하여 도구(클래스를 자동 생성하는)가 덮어쓰지 않도록 합니다.