조금 가지고 놀았고 현재 확장 유형 에 대한 개체를 사용하여 이 확장을 수행할 수 있으므로 잘 작동해야 합니다.

enum BasicEvents {
    Start = "Start",
    Finish = "Finish"
};

// extend enum using "extends" keyword
const AdvEvents = {
    ...BasicEvents,
    Pause: "Pause",
    Resume: "Resume"
};

참고하세요.

enum E {}

enum BasicEvents {
  Start = 'Start',
  Finish = 'Finish'
}
enum AdvEvents {
  Pause = 'Pause',
  Resume = 'Resume'
}
function enumerate<T1 extends typeof E, T2 extends typeof E>(e1: T1, e2: T2) {
  enum Events {
    Restart = 'Restart'
  }
  return Events as typeof Events & T1 & T2;
}

const e = enumerate(BasicEvents, AdvEvents);

필요에 따라 또 다른 옵션은 공용체 유형을 사용하는 것입니다.

const enum BasicEvents {
  Start = 'Start',
  Finish = 'Finish'
}
const enum AdvEvents {
  Pause = 'Pause',
  Resume = 'Resume'
}
type Events = BasicEvents | AdvEvents;

let e: Events = AdvEvents.Pause;

단점은 Events.Pause 를 사용할 수 없다는 것입니다. AdvEvents.Pause 를 사용해야 합니다. const 열거형을 사용하는 경우 아마도 괜찮을 것입니다. 그렇지 않으면 사용 사례에 충분하지 않을 수 있습니다.

강력한 형식의 Redux 감속기에 이 기능이 필요합니다. TypeScript에 추가해주세요.

또 다른 해결 방법은 열거형을 사용하지 않고 열거형처럼 보이는 것을 사용하는 것입니다.

const BasicEvents = {
  Start: 'Start' as 'Start',
  Finish: 'Finish' as 'Finish'
};
type BasicEvents = (typeof BasicEvents)[keyof typeof BasicEvents];

const AdvEvents = {
  ...BasicEvents,
  Pause: 'Pause' as 'Pause',
  Resume: 'Resume' as 'Resume'
};
type AdvEvents = (typeof AdvEvents)[keyof typeof AdvEvents];

모든 해결 방법은 좋지만 가능한 한 간단하게 철저한 검사를 사용할 수 있도록 typescript 자체에서 열거형 상속 지원을 보고 싶습니다.

enum 대신 class를 사용하십시오.

나는 이것을 시도하고 있었다.

const BasicEvents = {
    Start: 'Start' as 'Start',
    Finish: 'Finish' as 'Finish'
};

type BasicEvents = (typeof BasicEvents)[keyof typeof BasicEvents];

const AdvEvents = {
    ...BasicEvents,
    Pause: 'Pause' as 'Pause',
    Resume: 'Resume' as 'Resume'
};

type AdvEvents = (typeof AdvEvents)[keyof typeof AdvEvents];

type sometype<T extends AdvEvents> =
    T extends typeof AdvEvents.Start ? 'Some String' :
    T extends typeof AdvEvents.Finish ? 'Some Other String' :
    T extends typeof AdvEvents.Pause ? 'Abc' :
    T extends typeof AdvEvents.Resume ? 'Xyz' : never;
type r = sometype<typeof AdvEvents.Finish>;

이 작업을 수행하는 더 나은 방법이 있어야 합니다.

왜 이것이 이미 기능이 아닌가? 주요 변경 사항 없음, 직관적인 동작, 이 기능을 적극적으로 검색하고 요구하는 80명 이상의 사람들 - 그것은 당연한 일인 것 같습니다.

네임스페이스의 다른 파일에서 enum을 다시 내보내는 것조차 enum 을 확장하지 않고는 정말 이상합니다.

import { Foo as _Foo } from './Foo';

namespace Bar
{
    enum Foo extends _Foo {} // nope, doesn't work

    const Foo = _Foo;
    type Foo = _Foo;
}

Bar.Foo // actually not an enum

+1
현재 해결 방법을 사용 중이지만 기본 열거형 기능이어야 합니다.

나는 누군가가 다음 질문을 제기했는지 확인하기 위해 이 문제를 훑어보았다. (아닌 것 같다.)

OP에서:

enum BasicEvents {
    Start = "Start",
    Finish = "Finish"
};

// extend enum using "extends" keyword
enum AdvEvents extends BasicEvents {
    Pause = "Pause",
    Resume = "Resume"
};

사람들이 AdvEvents 를 BasicEvents 에 할당할 수 있을 거라고 기대할까요? (예를 들어 클래스의 경우 extends 인 경우와 같습니다.)

그렇다면 열거형 유형이 최종적이며 확장할 수 없다는 사실과 얼마나 잘 맞물리나요?

@masak 좋은 지적입니다. 사람들이 여기서 원하는 기능은 확실히 일반적인 extends 와 다릅니다. BasicEvents 는 AdvEvents 에 할당할 수 있어야 하며 그 반대로는 할당할 수 없습니다. 일반 extends 는 다른 유형을 보다 구체적으로 구체화하고 이 경우 다른 유형을 확장하여 더 많은 값을 추가하기를 원하므로 이에 대한 사용자 정의 구문은 아마도 extends 키워드를 사용하지 않아야 합니다. 또는 적어도 enum A extends B { 구문을 사용하지 마십시오.

그 점에서 나는 OP에서 이것에 대한 확산 제안을 좋아했습니다.

// extend enum using spread
enum AdvEvents {
    ...BasicEvents,
    Pause = "Pause",
    Resume = "Resume"
};

확산은 이미 원본이 연결되지 않은 복사본으로 얕게 복제될 것이라는 기대를 수반하기 때문입니다.

BasicEvents 는 AdvEvents 에 할당할 수 있어야 하며 그 반대는 아닙니다.

나는 그것이 모든 경우에 사실 일 수 있다는 것을 알 수 있지만, 제 말을 이해한다면 모든 경우에 그것이 사실 이어야 하는지 확신할 수 없습니다. 도메인 종속적이며 해당 열거형 값이 복사된 이유에 의존하는 것처럼 느껴집니다.

해결 방법에 대해 조금 더 생각하고 https://github.com/Microsoft/TypeScript/issues/17592#issuecomment -331491147 , 값에 Events 를 정의하여 조금 더 잘할 수 있습니다. 공간:

enum BasicEvents {
  Start = 'Start',
  Finish = 'Finish'
}
enum AdvEvents {
  Pause = 'Pause',
  Resume = 'Resume'
}
type Events = BasicEvents | AdvEvents;
const Events = {...BasicEvents, ...AdvEvents};

let e: Events = Events.Pause;

내 테스트에서 Events.Start 는 유형 시스템에서 BasicEvents.Start 로 올바르게 해석되어 철저한 검사 및 식별된 공용체 미세 조정이 잘 작동하는 것 같습니다. 가장 중요한 것은 Events.Pause 를 유형 리터럴로 사용할 수 없다는 것입니다. AdvEvents.Pause 가 필요합니다. typeof Events.Pause 를 사용할 수 있고 AdvEvents.Pause 로 해결됩니다. 비록 제 팀의 사람들이 그런 종류의 패턴으로 인해 혼란스러워 했으며 실제로 사용할 때 AdvEvents.Pause 를 권장한다고 생각합니다. 유형으로 합니다.

(이것은 열거형을 분리된 열거형이 아니라 서로 간에 할당할 수 있기를 원하는 경우입니다. 제 경험상 할당 가능하도록 하는 것이 가장 일반적입니다.)

또 다른 제안(원래의 문제를 해결하지 못하더라도), 대신 문자열 리터럴을 사용하여 형식 통합을 만드는 것은 어떻습니까?

type BEs = "Start" | "Finish";

type AEs = BEs | "Pause" | "Resume";

let example: AEs = "Finish"; // there is even autocompletion

그렇다면 우리의 문제에 대한 해결책은 이것이 될 수 있습니까?

const BasicEvents = {
    Start: "Start",
    Finish: "Finish"
};
// { Start: string, Finish: string };


const BasicEvents = {
    Start: "Start",
    Finish: "Finish"
} as const
// { Start: 'Start', Finish: 'Finish' };

https://github.com/Microsoft/TypeScript/pull/29510

열거형 확장은 TypeScript의 핵심 기능이어야 합니다. 그냥

@wottpal 이전 질문 반복:

[열거식 확장 가능]이라면 열거형 유형이 최종적이며 확장할 수 없다는 사실과 얼마나 잘 맞물리나요?

특히 열거형 값에 대한 switch 문의 전체 검사는 열거형의 비확장성에 따라 달라집니다.

@masak 뭐? 아니요, 그렇지 않습니다! 확장된 열거형은 더 넓은 유형이고 원래 열거형에 할당할 수 없기 때문에 항상 사용하는 모든 열거형의 모든 값을 알고 있습니다. 이 컨텍스트에서 확장한다는 것은 이전 열거형을 수정하는 것이 아니라 새 열거형을 만드는 것을 의미합니다.

enum A { a; }
enum B extends A { b; }

declare var a: A;
switch(a) {
    case A.a:
        break;
    default:
        // a is never
}

declare var b: B;
switch(b) {
    case A.a:
        break;
    default:
        // b is B.b
}

@m93a 아, 그래서 여기서 extends 가 실제로 더 많은 _copying_ 의미를 갖고 있다는 뜻인가요? ( A 에서 B $ 로의 열거형 값)? 그러면 스위치가 정상적으로 나옵니다.

그러나 여전히 나에게 깨진 것처럼 보이는 _일부_ 기대가 있습니다. 그것을 확실히 하기 위한 방법으로: 클래스에서 extends 는 복사 의미를 전달하지 _않습니다_ — 필드와 메소드는 확장 하위 클래스에 복사되지 않습니다. 대신 프로토타입 체인을 통해 사용할 수 있습니다. 수퍼 클래스에는 필드 또는 메소드가 하나만 있습니다.

이 때문에 class B extends A 이면 B 가 A 에 할당 가능하므로 예를 들어 let a: A = new B(); 가 완벽할 것입니다.

그러나 열거형 및 extends 를 사용하면 해당하는 보장이 없기 때문에 let a: A = B.b; 를 수행할 수 없습니다. 그것이 나에게 이상하게 느껴지는 것입니다. 여기서 extends 는 수행할 수 있는 작업에 대한 특정 가정 집합을 전달하며 열거형과 일치하지 않습니다.

그런 다음 expands 또는 clones ? 🤷‍♂️
사용자의 관점에서 볼 때 기본적인 것이 달성하기 쉽지 않은 것이 이상하게 느껴집니다.

합리적인 의미 체계에 완전히 새로운 키워드가 필요한 경우(다른 언어의 선행 기술이 거의 없음) OP 및 이 주석 에서 제안한 대로 확산 구문( ... )을 대신 사용하지 않는 이유는 무엇입니까?

+1 이것이 기본 열거 기능에 추가되기를 바랍니다. :)

누구든지 우아한 솔루션을 알고 있습니까 ??? 🧐

합리적인 의미 체계에 완전히 새로운 키워드가 필요한 경우(다른 언어의 선행 기술이 거의 없음) OP 및 이 주석에서 제안한 대로 스프레드 구문(...)을 대신 재사용하지 않는 이유는 무엇입니까?

네, 조금 더 생각해본 결과 이 ​​솔루션이 좋을 것 같습니다.

이 전체 문제 스레드를 읽은 후, 스프레드 연산자를 재사용하면 문제가 해결되고 구문을 혼동/직관적이지 않게 만드는 것에 대해 사람들이 제기한 모든 우려를 해결한다는 광범위한 동의가 있는 것으로 보입니다.

// extend enum using spread
enum AdvancedEvents {
    ...BasicEvents,
    Pause = "Pause",
    Resume = "Resume"
};

이 문제에 여전히 @RyanCavanaugh 라는 "추가 피드백 대기 중" 레이블이 필요합니까?

원하는 기능 +1

이 문제에 대한 소식이 있습니까? 열거형에 대해 확산 연산자를 구현하는 것은 정말 유용합니다.

특히 메타프로그래밍과 관련된 사용 사례의 경우 열거형을 별칭으로 지정하고 확장하는 기능은 필수품과 있으면 좋은 것 사이에 있습니다. 위에서 언급한 해결 방법 중 하나에 의존하지 않는 한 현재 하나의 열거형을 다른 이름으로 export 사용할 수 있는 방법이 없습니다.

@m93a 아, 그래서 여기서 extends 가 실제로 더 많은 _copying_ 의미를 갖고 있다는 뜻인가요? ( A 에서 B $ 로의 열거형 값)? 그러면 스위치가 정상적으로 나옵니다.

그러나 여전히 나에게 깨진 것처럼 보이는 _일부_ 기대가 있습니다. 그것을 확실히 하기 위한 방법으로: 클래스에서 extends 는 복사 의미를 전달하지 _않습니다_ — 필드와 메소드는 확장 하위 클래스에 복사되지 않습니다. 대신 프로토타입 체인을 통해 사용할 수 있습니다. 수퍼 클래스에는 필드 또는 메소드가 하나만 있습니다.

이 때문에 class B extends A 이면 B 가 A 에 할당 가능하므로 예를 들어 let a: A = new B(); 가 완벽할 것입니다.

그러나 열거형 및 extends 를 사용하면 해당하는 보장이 없기 때문에 let a: A = B.b; 를 수행할 수 없습니다. 그것이 나에게 이상하게 느껴지는 것입니다. 여기서 extends 는 수행할 수 있는 작업에 대한 특정 가정 집합을 전달하며 열거형과 일치하지 않습니다.

@masak 나는 당신이 정확에 가깝다고 생각하지만 하나의 작은 가정이 잘못되었습니다. enum B extends A 의 경우 B 는 A에 할당할 수 있습니다. "할당 가능"은 A가 제공한 모든 값을 B에서 사용할 수 있음을 의미합니다. let a: A = B.b 라고 말할 때 B의 값은 다음과 같아야 한다고 가정합니다. A에서 사용할 수 있는 값은 A에 할당할 수 있는 값과 다릅니다. B는 A에 할당할 수 있으므로 let a: A = B.a 가 맞습니다.

이것은 다음 예제와 같은 클래스를 사용하면 분명합니다.

class A {
 a() {}
}

class B extends A {
 b() {}
}

let a: A = new B();

a.a();  // valid
a.b();  // invalid via type system since `a` is typed as `A`

TypeScript 플레이그라운드 링크

간단히 말해서, 나는 extends IS가 정확히 수행되고 있는 정확한 용어라고 믿습니다. enum B extends A 예제에서 B 열거형은 A 열거형의 가능한 모든 값을 포함할 것이라고 항상 기대할 수 있습니다. A에게 할당할 수 있습니다.

그래서 저는 새로운 키워드가 필요하지 않다고 생각합니다. extends를 사용해야 한다고 생각합니다. 그리고 이것이 기본적으로 TypeScript의 일부여야 한다고 생각합니다 :D

@julian-sf 나는 당신이 쓴 모든 것에 동의한다고 생각합니다 ...

...하지만... :약간_웃는_얼굴:

여기서 문제를 제기한 것처럼 이 상황은 어떻습니까?

// example from OP
enum BasicEvents {
    Start = "Start",
    Finish = "Finish"
};

// extend enum using "extends" keyword
enum AdvEvents extends BasicEvents {
    Pause = "Pause",
    Resume = "Resume"
};

Pause 가 AdvEvents #$ 의 _instance_이고 AdvEvents _extens_ BasicEvents 인 경우 Pause 도 BasicEvents #의 _instance_가 될 것으로 예상하시겠습니까?

반면에 열거형(IMHO)의 핵심 가치 제안은 switch 문과 같은 것이 전체성을 가정할 수 있도록 열거형이 _closed_/"최종"(확장 불가)이라는 것입니다. (따라서 AdvEvents 가 BasicEvent 가 된다는 의미를 _extend__ 할 수 있다는 것은 enum에 대한 일종의 Least Surprise를 위반하는 것입니다.)

다음 세 가지 속성 중 두 개 이상을 사용할 수 없다고 생각합니다.

• 마감 중인 열거형/최종/예상 가능한 총계
• 두 enum 선언 간의 extends 관계
• b 가 B 및 B extends A 의 인스턴스이면 b 가 A 의 인스턴스라는 (합리적인) 가정

@masak 나는 enum의 폐쇄형 원칙(런타임 시)을 이해하고 동의합니다. 그러나 컴파일 시간 확장은 모두 컴파일러에 의해 정의 및 구성되므로 런타임 시 폐쇄 원칙을 위반하지 않습니다.

b가 B의 인스턴스이고 B가 A를 확장하면 b가 A의 인스턴스라는 (합리적인) 가정

인스턴스/클래스 이분법이 실제로 열거형에 할당할 수 없기 때문에 이 추론은 일종의 오해의 소지가 있다고 생각합니다. 열거형은 클래스가 아니며 인스턴스가 없습니다. 그러나 적절하게 수행되면 확장할 수 있다고 생각합니다. 열거형을 집합과 더 유사하게 생각하십시오. 이 예에서 B는 A의 상위 집합입니다. 따라서 A의 모든 값이 B에 있지만 B의 일부 값만 A에 있다고 가정하는 것이 합리적입니다.

우려가 어디에서 오는지 이해합니다...하지만. 그리고 나는 그것에 대해 무엇을해야할지 잘 모르겠습니다. 열거형 확장 문제의 좋은 예:

const enum A { a = 'a' }
const enum B extends A { b = 'b' }

const foo = (a: A) => console.log(a);
const bar = (b: B) => foo(b);

bar(B.a); // 'a'
bar(B.b); // uh-oh, b doesn't exist on A, so foo would get unexpected behavior

// HOWEVER, this would work just fine...

const baz = (a: A) => bar(a);

baz(A.a); // 'a'
baz(B.a); // 'a'
baz(B.b); // compiler error as expected...

이 경우 열거형은 클래스와 매우 다르게 동작합니다. 이것이 클래스라면 B를 A로 아주 쉽게 형변환할 수 있을 거라고 예상하겠지만 여기서는 분명히 작동하지 않을 것입니다. 나는 이것이 반드시 나쁘다고 생각하지 않습니다. 나는 그것이 단지 설명되어야 한다고 생각합니다. IE에서는 클래스처럼 상속 트리에서 열거형 유형의 범위를 위쪽으로 지정할 수 없습니다. 이것은 "B의 모든 값이 A에 존재하지 않기 때문에 상위 집합 열거형 B를 A에 할당할 수 없습니다"라는 컴파일러 오류로 설명될 수 있습니다.

@julian-sf

인스턴스/클래스 이분법이 실제로 열거형에 할당할 수 없기 때문에 이 추론은 일종의 오해의 소지가 있다고 생각합니다. 열거형은 클래스가 아니며 인스턴스가 없습니다.

당신의 말이 절대적으로 옳습니다.

• 독립적인 언어 구성으로 볼 때 열거형에는 인스턴스가 아니라 _구성원_이 있습니다. "회원"이라는 용어는 핸드북과 언어 사양에서 모두 사용됩니다. (C#과 Python은 유사하게 "멤버"라는 용어를 사용합니다. Java에서는 "멤버"가 오버로드된 의미를 갖기 때문에 Java는 "열거형 상수"를 사용합니다.)
• 컴파일된 코드 관점에서 볼 때 열거형에는 _properties_가 있어 이름에서 값으로, 값에서 이름으로 매핑됩니다. 다시 말하지만 인스턴스가 아닙니다.

이것에 대해 생각하면서, 나는 내가 열거형에 대한 Java의 견해에 약간 영향을 받았다는 것을 깨달았습니다. Java에서 열거형 값은 말 그대로 열거형 유형의 인스턴스입니다. 구현 측면에서 열거형은 Enum 클래스를 확장하는 클래스 입니다. ( 수동으로 수행할 수 없으며 enum 키워드를 거쳐야 하지만 이것이 내부적으로 발생합니다.) 이것에 대한 좋은 점은 열거형이 클래스가 하는 모든 편의를 얻는다는 것입니다. 필드, 생성자, 메소드를 가질 수 있습니다... 이 접근 방식에서 열거형 멤버는 _are_ 인스턴스입니다. (JLS는 그렇게 말합니다.)

TypeScript 열거 의미 체계에 대한 변경을 제안하지 않습니다. 특히 TypeScript가 열거형에 대해 Java 모델을 사용하도록 변경되어야 한다고 말하는 것이 아닙니다. 열거형/열거형 멤버 위에 클래스/인스턴스 "이해"를 오버레이하는 것이 유익하고 통찰력이 있다는 _am_입니다. "enum _is_ class" 또는 "an enum member _is_ instance"가 아니라... 하지만 이월되는 유사점이 있습니다.

어떤 유사점? 먼저 회원가입을 입력합니다.

enum Foo { A, B, C }
enum Bar { X, Y, Z }

let foo: Foo = Foo.C;
foo = Bar.Z;

Bar.Z 가 Foo 이 아니기 때문에 마지막 줄은 typecheck 하지 않습니다. 다시 말하지만, 이것은 _실제로는_ 클래스 및 인스턴스가 아니지만 Foo 및 Bar 가 클래스이고 6명의 멤버가 각각의 인스턴스인 것처럼 동일한 모델을 사용하여 _이해_할 수 있습니다.

(이 인수의 목적을 위해 let foo: Foo = 2; 도 의미상 합법적이고 일반적으로 number 값은 열거형 유형의 변수에 할당할 수 있다는 사실을 무시합니다.)

열거형에는 _closed_라는 추가 속성이 있습니다. 죄송합니다. 이에 대한 더 나은 용어는 모르겠습니다. 일단 정의하면 확장할 수 없습니다. 특히 열거형 선언 내부에 나열된 멤버는 열거형 유형과 유형이 일치하는 _only_ 항목입니다. ("폐쇄 세계 가설"에서와 같이 "닫힘".) 열거형의 switch 문에 있는 모든 사례가 포함되었는지 완전히 확실하게 확인할 수 있기 때문에 이것은 훌륭한 속성입니다.

열거형에 extends 를 사용하면 이 속성이 창 밖으로 사라집니다.

당신은 쓰기,

열거형의 폐쇄 원칙(런타임 시)을 이해하고 동의합니다. 그러나 컴파일 시간 확장은 모두 컴파일러에 의해 정의 및 구성되므로 런타임 시 폐쇄 원칙을 위반하지 않습니다.

열거형을 확장하는 모든 코드가 프로젝트에 있다고 가정하기 때문에 그것이 사실이 아니라고 생각합니다. 그러나 타사 모듈이 열거형을 확장할 수 있으며 갑자기 컴파일하는 코드의 제어를 벗어나 열거형에 할당할 수 있는 _new_ 열거형 멤버가 있습니다. 기본적으로 열거형은 컴파일 타임에도 더 이상 닫히지 않습니다.

나는 여전히 내가 의미하는 바를 정확하게 표현하는 데 다소 서툴다고 생각하지만, 그것이 중요하다고 생각합니다. $# enum 의 extends 는 열거형의 가장 소중한 기능 중 하나를 깨뜨릴 것입니다. 다시 폐쇄. 바로 이러한 이유로 열거형을 확장/하위 분류하는 것을 절대적으로 _금지_하는 언어가 몇 개인지 계산하십시오.

해결 방법에 대해 조금 더 생각하고 #17592 (comment) , 값 공간에 Events 를 정의하여 조금 더 잘할 수 있습니다.

enum BasicEvents {
  Start = 'Start',
  Finish = 'Finish'
}
enum AdvEvents {
  Pause = 'Pause',
  Resume = 'Resume'
}
type Events = BasicEvents | AdvEvents;
const Events = {...BasicEvents, ...AdvEvents};

let e: Events = Events.Pause;

내 테스트에서 Events.Start 는 유형 시스템에서 BasicEvents.Start 로 올바르게 해석되어 철저한 검사 및 식별된 공용체 미세 조정이 잘 작동하는 것 같습니다. 가장 중요한 것은 Events.Pause 를 유형 리터럴로 사용할 수 없다는 것입니다. AdvEvents.Pause 가 필요합니다. typeof Events.Pause 를_사용할 수 있고 AdvEvents.Pause 로 해결됩니다. 비록 제 팀의 사람들이 그런 종류의 패턴으로 혼란스러워 했으며 실제로 사용할 때 AdvEvents.Pause 를 권장하고 싶습니다. 유형으로 합니다.

(이것은 열거형을 분리된 열거형이 아니라 서로 간에 할당할 수 있기를 원하는 경우입니다. 제 경험상 할당 가능하도록 하는 것이 가장 일반적입니다.)

나는 이것이 현재 손에 있는 가장 깔끔한 솔루션이라고 생각합니다.

@alangpierce 감사합니다 :+1:

이것에 대한 어떤 업데이트?

@sdwvit 저는 핵심적인 사람은 아니지만 제 관점에서 볼 때 다음 구문 제안(OP에서, 그러나 그 후 두 번 다시 제안됨)은 알려진 문제 없이 모두를 행복하게 만들 것입니다.

// extend enum using spread
enum AdvEvents {
    ...BasicEvents,
    Pause = "Pause",
    Resume = "Resume"
};

extends 를 사용하지 않고 _없이_ 이 유용해 보이는 "이 다른 열거형의 모든 구성원 복제" 기능을 구현하는 것을 의미하기 때문에 _me_는 행복할 것입니다. ... 구문은 확장이 아닌 복사를 통해 이러한 문제를 방지합니다.

이 문제는 여전히 "추가 피드백 대기 중"으로 표시되어 있으며, 필요하다고 느끼는 동안 해당 범주에 해당 항목을 유지할 수 있는 핵심 구성원의 권리를 존중합니다. 그러나 또한 위의 사항을 구현하고 PR로 제출하는 것을 막을 수 있는 방법은 없습니다.

@masak 님 답변 감사합니다. 이제 모든 토론 기록을 살펴봐야 합니다. 이후에 다시 연락드리겠습니다 :)

나는 이것이 일어나는 것을 절대적으로 보고 싶고 이것을 직접 구현하려고 시도하는 것을 절대적으로 좋아할 것입니다. 그러나 여전히 모든 열거형에 대한 동작을 정의해야 합니다. 이 모든 것은 문자열 기반 열거형에 대해 잘 작동하지만 바닐라 숫자 열거형은 어떻습니까? 여기에서 확장/복사는 어떻게 작동합니까?

• "동일한 유형" 열거형(숫자는 숫자 확장, 문자열 확장 문자열)로 열거형 확장만 허용하고 싶다고 가정합니다. 이기종 열거형 은 기술적으로 지원되므로 그 지원을 유지해야 한다고 생각합니다.

• 여러 열거형에서 확장을 허용해야 합니까? 그것들은 모두 상호 배타적인 가치를 가져야 합니까? 아니면 겹치는 값을 허용합니까? 어휘 순서에 따른 우선 순위?

• 확장 열거형이 확장 열거형 값을 재정의할 수 있습니까?

• 확장된 열거형이 값 목록의 시작으로 나타나야 합니까 아니면 임의의 순서로 있을 수 있습니까? 나중에 정의된 값이 더 높은 우선 순위를 갖는다고 가정합니까?

• 암시적 숫자 값은 확장 숫자 열거형의 최대값 이후에 계속 1이라고 가정합니다.

• 비트 마스크에 대한 특별한 고려 사항?

등 등

@JeffreyMercado 이것은 좋은 질문이며 구현을 시도하려는 사람에게 적합합니다. :웃다:

아래는 "보수적인" 디자인 접근 방식에 따라 안내된 내 답변입니다("이전 버전과의 호환성을 유지하면서 나중에 변경하기 어려운 지금 선택을 하기보다 확실하지 않은 경우를 허용하지 않는 디자인 결정을 내리자").

• "같은 유형" 열거형으로 열거형을 확장하는 것만 허용한다고 가정합니다(숫자는 숫자 확장, 문자열 확장 문자열)

저도 그렇게 생각합니다. 혼합 유형의 결과 열거형은 그다지 유용하지 않은 것 같습니다.

• 여러 열거형에서 확장을 허용해야 합니까? 그것들은 모두 상호 배타적인 가치를 가져야 합니까? 아니면 겹치는 값을 허용합니까? 어휘 순서에 따른 우선 순위?

우리가 말하는 의미 체계를 복사하기 때문에 여러 열거형을 복제하는 것이 C++에서 다중 상속보다 "더 괜찮은" 것처럼 보입니다. 특히 객체 확산의 유추를 계속 구축하면 문제가 발생하지 않습니다. let newEnum = { ...enumA, ...enumB };

모든 구성원이 상호 배타적인 가치를 가져야 합니까? 보수적인 것은 "예"라고 말하는 것입니다. 다시 말하지만, 객체 확산의 비유는 우리에게 대안적인 의미를 제공합니다: 마지막 것이 이깁니다.

열거형 값을 재정의할 수 있는 사용 사례를 생각할 수 없습니다. 하지만 그건 제 상상력 부족일 수도 있어요. 충돌을 허용하지 않는 보수적인 접근 방식은 설명/내부화하기 쉽고 적어도 이론상 실제 디자인 오류(신선한 코드 또는 유지 관리 중인 코드에서)를 노출할 수 있다는 즐거운 속성을 가지고 있습니다.

• 확장 열거형이 확장 열거형 값을 재정의할 수 있습니까?

나는 대답과 추론이 이전의 경우와 마찬가지로 이 경우에도 거의 같다고 생각합니다.

• 확장된 열거형이 값 목록의 시작으로 나타나야 합니까 아니면 임의의 순서로 있을 수 있습니까? 나중에 정의된 값이 더 높은 우선 순위를 갖는다고 가정합니까?

나는 우선 이것이 "마지막이 이기다"라는 의미의 재정의를 사용하는 경우에만 중요하다고 말하려고 했습니다.

그러나 다시 생각해 보면 "충돌 없음"과 "마지막이 승리" 모두에서 열거형이 목록에 퍼지기 전에 열거형 멤버 선언을 _원하는_ 것조차 이상하다고 생각합니다. 예를 들어, 그렇게 함으로써 어떤 의도가 전달되고 있습니까? 스프레드는 "수입품"과 약간 비슷하며 일반적으로 맨 위에 있습니다.

열거형 멤버 선언 뒤에 열거형 스프레드를 넣는 것을 반드시 금지하고 싶지는 않습니다(문법에서 허용되지 않는 것이 좋다고 생각하지만). 그것이 결국 허용된다면, 그것은 분명히 린터와 커뮤니티 컨벤션이 피할 수 있는 것으로 지적할 수 있는 것입니다. 그렇게 해야 할 설득력 있는 이유가 없습니다.

• 암시적 숫자 값은 확장 숫자 열거형의 최대값 이후에 계속 1이라고 가정합니다.

아마도 보수적으로 해야 할 일은 스프레드 후 첫 번째 구성원에 대해 명시적 값을 요구하는 것입니다.

• 비트 마스크에 대한 특별한 고려 사항?

위의 규정에 해당한다고 생각합니다.

열거형, 인터페이스 및 변경할 수 없는 개체를 결합하여 합리적인 작업을 수행할 수 있었습니다.

export enum Unit {
    SECONDS,
    MINUTES,
    HOURS,
    DAYS,
    WEEKS,
    MONTHS,
    YEARS,
    DECADES,
    CENTURIES,
    MILLENNIA
}

interface Labels {
    SINGULAR: Record<Unit, string>
    PLURAL: Record<Unit, string>
    LAST: string;
    DELIM: string;
    NOW: string;
}

export const EnglishLabels: Labels = {
    SINGULAR: {
        [Unit.SECONDS]: ' second',
        [Unit.MINUTES]: ' minute',
        [Unit.HOURS]: ' hour',
        [Unit.DAYS]: ' day',
        [Unit.WEEKS]: ' week',
        [Unit.MONTHS]: ' month',
        [Unit.YEARS]: ' year',
        [Unit.DECADES]: ' decade',
        [Unit.CENTURIES]: ' century',
        [Unit.MILLENNIA]: ' millennium'
    },
    PLURAL: {
        [Unit.SECONDS]: ' seconds',
        [Unit.MINUTES]: ' minutes',
        [Unit.HOURS]: ' hours',
        [Unit.DAYS]: ' days',
        [Unit.WEEKS]: ' weeks',
        [Unit.MONTHS]: ' months',
        [Unit.YEARS]: ' years',
        [Unit.DECADES]: ' decades',
        [Unit.CENTURIES]: ' centuries',
        [Unit.MILLENNIA]: ' millennia'
    },
    LAST: ' and ',
    DELIM: ', ',
    NOW: ''
}

@illeatmyhat 열거형을 잘 사용하는 것이지만... 기존 열거형을 확장하는 것으로 간주되는 방법을 알 수 없습니다. 당신이하고있는 일은 열거 형을 _사용_하는 것입니다.

(또한 enum 및 switch 문과 달리 귀하의 예에서는 전체 검사가 없는 것 같습니다. 나중에 enum 멤버를 추가한 사람이 SINGULAR 및 PLURAL 에 해당 키를 추가하는 것을 잊었을 수 있습니다. Label 의 모든 인스턴스에서 PLURAL 레코드)

@masak

나중에 열거형 멤버를 추가한 사람은 Label 의 모든 인스턴스에서 SINGULAR 및 PLURAL 레코드에 해당 키를 추가하는 것을 쉽게 잊어버릴 수 있습니다.

적어도 내 환경에서는 열거형 멤버가 SINGULAR 또는 PLURAL 에서 누락되면 오류가 발생합니다. Record 유형이 제 역할을 하는 것 같습니다.

TS에 대한 문서 는 훌륭하지만 많은 기능을 사소한 방식으로 결합하는 방법에 대한 예는 많지 않다고 생각합니다. enum inheritance 는 국제화 문제를 해결하려고 할 때 이 스레드로 이어진 첫 번째 항목이었습니다. 어쨌든 접근 방식이 잘못된 것으로 밝혀져 이 포스트를 작성하게 되었습니다.

@illeatmyhat

적어도 내 환경에서는 열거형 멤버가 SINGULAR 또는 PLURAL 에서 누락되면 오류가 발생합니다. Record 유형이 제 역할을 하는 것 같습니다.

오! 틸. 그리고 예, 그것은 훨씬 더 흥미롭게 만듭니다. 처음에는 열거형 상속에 도달하고 결국에는 패턴에 도달하는 것에 대해 의미하는 바를 알 수 있습니다. 그것은 고립된 일이 아닐 수도 있습니다. "X/Y 문제"는 현실입니다. 더 많은 사람들이 " MyEnum 를 확장하고 싶다"는 생각으로 시작했지만 결국에는 Record<MyEnum, string> 를 사용하게 될 것입니다.

@masak 에 답장:

열거형에 확장을 사용하면 이 속성이 창 밖으로 사라집니다.

당신은 쓰기,

@julian-sf: (런타임 시) 열거형의 폐쇄 원칙을 이해하고 동의합니다. 그러나 컴파일 시간 확장은 모두 컴파일러에 의해 정의 및 구성되므로 런타임 시 폐쇄 원칙을 위반하지 않습니다.

열거형을 확장하는 모든 코드가 프로젝트에 있다고 가정하기 때문에 그것이 사실이 아니라고 생각합니다. 그러나 타사 모듈은 열거형을 확장할 수 있으며 갑자기 컴파일하는 코드의 제어를 벗어나 열거형에도 할당할 수 있는 새 열거형 멤버가 있습니다. 기본적으로 열거형은 컴파일 타임에도 더 이상 닫히지 않습니다.

내가 이것에 대해 생각하면, 당신은 완전히 맞습니다. 열거형은 닫아야 합니다. 열거형을 "작성"한다는 아이디어가 정말 마음에 듭니다. 이것이 우리가 여기서 원하는 문제의 핵심이라고 생각하기 때문입니다. 🥳.

이 표기법은 두 개의 개별 열거형을 "함께 꿰매는" 개념을 매우 우아하게 요약한다고 생각합니다.

enum ComposedEnum = { ...EnumA, ...EnumB }

따라서 extends 라는 용어를 사용하는 것에 대한 나의 사임을 고려하십시오 😆

@JeffreyMercado의 질문에 대한 @masak 의 답변에 대한 댓글:

• "동일한 유형" 열거형(숫자는 숫자 확장, 문자열 확장 문자열)로 열거형 확장만 허용하고 싶다고 가정합니다. 이기종 열거형은 기술적으로 지원되므로 그 지원을 유지해야 한다고 생각합니다.

저도 그렇게 생각합니다. 혼합 유형의 결과 열거형은 그다지 유용하지 않은 것 같습니다.

유용하지 않다는 데 동의하지만 여기에서 열거형에 대한 이기종 지원을 유지해야 합니다(SHOULD). 여기서 linter 경고가 유용할 것이라고 생각하지만 TS가 이를 방해해서는 안 된다고 생각합니다. 나는 인위적인 사용 사례를 생각할 수 있습니다. 즉, 숫자와 문자열이 혼합된 플래그를 사용하는 매우 잘못 설계된 API와의 상호 작용을 위한 열거형을 구축하고 있습니다. 의도적이라는 건 압니다. 하지만 다른 곳에서는 허용되기 때문에 여기에서 허용하지 않아야 한다고 생각합니다.

그냥 하지 말라는 강한 격려가 아닐까요?

• 여러 열거형에서 확장을 허용해야 합니까? 그것들은 모두 상호 배타적인 가치를 가져야 합니까? 아니면 겹치는 값을 허용합니까? 어휘 순서에 따른 우선 순위?

우리가 말하는 의미 체계를 복사하기 때문에 여러 열거형을 복제하는 것이 C++에서 다중 상속보다 "더 괜찮은" 것처럼 보입니다. 특히 객체 확산의 유추를 계속 구축하는 경우 문제를 즉시 알 수 없습니다. let newEnum = { ...enumA, ...enumB };

100% 동의

• 모든 구성원이 상호 배타적인 가치를 가져야 합니까?

보수적인 것은 "예"라고 말하는 것입니다. 다시 말하지만, 객체 확산의 비유는 우리에게 대안적인 의미를 제공합니다: 마지막 것이 이깁니다.

나는 여기에서 찢어졌다. 나는 가치의 상호 배타성을 시행하는 것이 "모범 사례"라는 데 동의하지만 그것이 맞습니까? 일반적으로 알려진 확산 의미와 직접적으로 모순됩니다. 한편으로는 상호 배타적인 가치를 적용한다는 아이디어가 마음에 들지만, 다른 한편으로는 확산 의미 체계가 작동하는 방식에 대한 많은 가정을 깨뜨립니다. "최후의 승리"로 일반적인 살포 규칙을 따를 때 단점이 있습니까? 구현이 더 쉬운 것처럼 보입니다(기본 개체가 어쨌든 지도일 뿐이기 때문에). 그러나 그것은 또한 일반적인 기대와 일치하는 것 같습니다. 덜 놀라는 쪽으로 기울고 있습니다.

값을 재정의하려는 좋은 예도 있을 수 있습니다(그 값이 무엇인지는 모르지만).

그러나 다시 생각해보면 "충돌 없음"과 "마지막이 승리" 둘 다 목록에서 열거형이 퍼지기 전에 열거형 멤버 선언을 넣고 싶어하는 것조차 이상합니다. 예를 들어, 그렇게 함으로써 어떤 의도가 전달되고 있습니까? 스프레드는 "수입품"과 약간 비슷하며 일반적으로 맨 위에 있습니다.

글쎄, 그것은 우리가 확산 의미론을 따른다면 순서가 무엇인지는 중요하지 않아야 합니다. 솔직히, 상호 배타적인 값을 적용하더라도 순서는 별로 중요하지 않겠죠? 충돌은 순서에 관계없이 해당 지점에서 오류가 됩니다.

• 암시적 숫자 값은 확장 숫자 열거형의 최대값 이후에 계속 1이라고 가정합니다.

아마도 보수적으로 해야 할 일은 스프레드 후 첫 번째 구성원에 대해 명시적 값을 요구하는 것입니다.

동의한다. 열거형을 퍼뜨리면 TS는 추가 구성원에 대해 명시적 값을 적용해야 합니다.

@julian-sf

그러니 내 사임 기간이 연장된다고 생각해 😆

:+1: 화폐보존협회가 옆에서 환호합니다.

그러나 다시 생각해보면 "충돌 없음"과 "마지막이 승리" 둘 다 목록에서 열거형이 퍼지기 전에 열거형 멤버 선언을 넣고 싶어하는 것조차 이상합니다. 예를 들어, 그렇게 함으로써 어떤 의도가 전달되고 있습니까? 스프레드는 "수입품"과 약간 비슷하며 일반적으로 맨 위에 있습니다.

글쎄, 그것은 우리가 확산 의미론을 따른다면 순서가 무엇인지는 중요하지 않아야 합니다. 솔직히, 상호 배타적인 값을 적용하더라도 순서는 별로 중요하지 않겠죠? 충돌은 순서에 관계없이 해당 지점에서 오류가 됩니다.

나는 "정상적인 회원 선언 후에 스프레드를 배치할 타당한 이유가 없다"고 말하고 있습니다. "적절한 제한 사항에 따라 앞이나 뒤에 배치해도 차이가 없습니다"라고 말하고 있습니다. 이 두 가지는 동시에 사실일 수 있습니다.

결과의 주요 차이점은 일반 회원보다 먼저 스프레드를 허용하거나 허용하지 않는 범위에 있는 것 같습니다. 구문상 허용되지 않을 수 있습니다. 린터 경고를 생성할 수 있습니다. 또는 모든면에서 완전히 괜찮을 수 있습니다. 순서가 의미 론적 차이가 없다면 열거 형 스프레드 기능이 최소 놀라움 의 원칙을 따르고 사용하기 쉽고 가르치거나 설명하기 쉽도록 만드는 것입니다.

스프레드 연산자를 사용하면 JS 및 TypeScript 전체에서 얕은 복사가 더 광범위하게 사용됩니다. 직접적인 관계를 암시하는 extends 를 사용하는 것보다 확실히 더 널리 사용되고 이해하기 쉬운 방법입니다. 구성을 통해 열거형을 만드는 것이 더 사용하기 쉬운 솔루션이 될 것입니다.

제안 해결 방법 중 일부는 유효하고 사용 가능하지만 원하는 동일한 결과를 얻기 위해 훨씬 더 많은 상용구 코드를 추가합니다. 열거형의 최종적이고 변경할 수 없는 특성을 고려할 때 다른 언어와 일관된 속성을 유지하려면 구성을 통해 추가 열거형을 만드는 것이 바람직합니다.

이 대화의 3년이 아직 진행 중이라는 것이 유감입니다.

@jmitchell38488 귀하의 댓글에 좋아요를 표시하고 싶지만 귀하의 마지막 문장이 제 마음을 바꿨습니다. 제안된 솔루션이 작동할 것이기 때문에 이것은 필요한 토론이지만 클래스와 인터페이스를 이러한 방식으로 확장할 가능성도 내포하고 있습니다. 이는 기본적으로 동일한 작업을 수행하는 두 가지 방법( class A extends B 및 class A { ...(class B {}) } )으로 끝나기 때문에 일부 C++ 유사 언어 프로그래머가 typescript를 사용하는 것을 두려워할 수 있는 큰 변화입니다. 내 생각에는 두 가지 방법 모두 지원될 수 있지만 일관성을 위해 열거형에도 extend 가 필요합니다.

@masak wdyt? ^^

@sdwvit 나는 클래스와 인터페이스를 생성하기 위한 동작을 변경하는 것에 대해 취하는 것이 아니라 열거형에 대해 구체적으로 이야기하고 구성을 통해 생성하는 것에 대해 이야기하고 있습니다. 그것들은 변경할 수 없는 최종 유형이므로 일반적인 상속 방식으로 확장할 수 없어야 합니다.

JS의 특성과 최종 트랜스파일된 값을 감안할 때 합성이 이루어지지 않을 이유가 없습니다. 물론 열거 형 작업을 더 매력적으로 만들 것입니다.

@masak wdyt? ^^

흠. 언어 일관성은 칭찬할 만한 목표라고 생각합니다. 따라서 클래스와 인터페이스에서 유사한 ... 기능을 요청하는 것은 _선험적으로_ 잘못된 것이 아닙니다. 그러나 나는 그 사례가 더 약하거나 존재하지 않는다고 생각하며 두 가지 이유 때문에: (a) 클래스와 인터페이스에는 이미 확장 메커니즘이 있고 두 번째를 추가하면 추가 가치가 거의 없습니다(열거형에 하나를 제공하면 사람들이 몇 년 동안 이 문제로 다시 돌아왔습니다); (b) 클래스에 새로운 구문과 의미를 추가하는 것은 승인을 위한 기준이 훨씬 더 높습니다. 클래스는 어떤 의미에서는 EcmaScript 사양에서 따온 것이기 때문입니다. (TypeScript는 ES6보다 오래되었지만 전자를 후자에 가깝게 유지하려는 적극적인 노력이 있었습니다. 여기에는 맨 위에 추가 기능을 도입하지 않는 것이 포함됩니다.)

나는 이 스레드가 실제 사용 사례를 다룰 가치가 있는 기능을 나타내기 때문에 오랫동안 열려 있다고 생각하지만 아직 PR을 얻지 못했습니다. 그러한 PR을 하려면 단순히 기능을 원한다고 말하는 것보다 더 많은 시간과 노력이 필요합니다. :눈짓:

이 기능을 작업하는 사람이 있습니까?

이 기능을 작업하는 사람이 있습니까?

우리가 그것에 대한 토론을 끝내지 않았기 때문에 내 생각에는 아니요, 하하!

이것이 어떻게 생겼는지에 대한 합의에 가까워진 것 같습니다. 이것은 언어 추가이기 때문에 이 제안을 추진하려면 "챔피언"이 필요할 것입니다. TS 팀의 누군가가 와서 "피드백 대기 중"에서 "제안 대기 중"(또는 이와 유사한 것)으로 문제를 이동해야 한다고 생각합니다.

나는 그것의 프로토 타입을 작업 중입니다. 비록 시간이 부족하고 코드 구조에 익숙하지 않기 때문에 멀리 가지 못했습니다. 나는 이것을 끝까지보고 싶고 다른 움직임이 없다면 할 수있을 때 계속할 것입니다.

이 기능도 좋아할 것입니다. 37개월이 지났습니다. 빨리 진행되기를 바랍니다.

최근 회의 메모:

• extends 는 하위 유형을 의미하는 반면 열거형을 "확장"하면 상위 유형이 생성되기 때문에 우리는 스프레드 구문을 좋아합니다.

  enum BasicEvents {
   Start = "Start",
   Finish = "Finish"
  }
  enum AdvEvents {
   ...BasicEvents,
   Pause = "Pause",
   Resume = "Resume"
  }
  

• AdvEvents.Start 는 BasicEvents.Start 와 동일한 유형 ID로 해석됩니다. 이는 BasicEvents.Start 및 AdvEvents.Start 유형이 서로 할당 가능하고 BasicEvents 유형이 $ AdvEvents 에 할당될 수 있음을 의미합니다. 이것이 직관적으로 이해되기를 바라지만, 이것이 의미하는 대로 스프레드를 확장하면 스프레드가 단순한 구문상의 지름길이 아니라는 것을 의미한다는 점에 유의하는 것이 중요합니다.

  enum BasicEvents {
   Start = "Start",
   Finish = "Finish"
  }
  enum AdvEvents {
   Start = "Start",
   Finish = "Finish",
   Pause = "Pause",
   Resume = "Resume"
  }
  

  이것은 다른 동작을 합니다. 여기서 BasicEvents.Start 및 AdvEvents.Start 는 문자열 열거형의 불투명한 품질로 인해 서로 할당할 수 _없습니다_.

  이 구현의 또 다른 사소한 결과는 AdvEvents.Start 가 빠른 정보 및 선언 방출에서 BasicEvents.Start 로 직렬화된다는 것입니다(적어도 AdvEvents 에 멤버를 연결하는 구문 컨텍스트가 없는 경우). — AdvEvents.Start 리터럴 표현식 위로 마우스를 가져가면 AdvEvents.Start 라는 빠른 정보가 나올 수 있지만 그럼에도 불구하고 BasicEvents.Start 를 표시하는 것이 더 명확할 수 있습니다.

• 이것은 문자열 열거형에서만 허용됩니다.

나는 이것을 시도하고 싶다.

명확히 하기 위해: 이것은 구현을 위해 승인되지 않았습니다.

여기에는 두 가지 가능한 동작이 있으며 둘 다 좋지 않습니다.

옵션 1: 사실 설탕입니다

Spread가 실제로 spreaded enum의 멤버를 복사하는 것과 같은 의미라면 사람들이 확장 enum의 값을 확장 enum의 값인 것처럼 사용하려고 하면 작동하지 않는 큰 놀라움이 있을 것입니다.

옵션 2: 실제로 설탕이 아닙니다.

선호되는 옵션은 스프레드가 스레드 상단 근처에서 @aj-r의 통합 유형 제안과 ​​더 유사하게 작동하는 것입니다. 그것이 사람들이 이미 원하는 행동이라면 테이블에 있는 기존 옵션이 이해를 돕기 위해 엄격하게 선호되는 것처럼 보입니다. 그렇지 않으면 우리는 다른 문자열 열거형처럼 작동하지 않는 새로운 종류의 문자열 열거형을 만들고 있습니다. 이는 이상하고 여기 제안의 "단순함"을 훼손하는 것 같습니다.

사람들은 어떤 행동을 원하며 그 이유는 무엇입니까?

나는 큰 놀라움으로 이어지기 때문에 옵션 1을 원하지 않습니다.

옵션 2를 원하지만 언급된 @aj-r의 단점을 극복할 수 있는 충분한 구문 지원을 원하므로 그의 예제에서 let e: Events = Events.Pause; 를 작성할 수 있습니다. 단점은 끔찍하지 않지만 확장된 열거형이 구현을 숨길 수 없는 곳입니다. 그래서 좀 징그럽습니다.

나는 또한 옵션 1이 나쁜 생각이라고 생각합니다. 회사에서 이 문제에 대한 참조를 검색했고 링크된 두 개의 코드 리뷰를 찾았으며 두 경우 모두(내 개인적인 경험에서) 더 작은 열거형의 요소를 더 큰 열거형 유형에 할당할 수 있어야 한다는 분명한 필요성이 있습니다. . 특히 한 사람이 ... 를 도입하여 옵션 2처럼 행동한다고 ​​생각하고 다음 사람이 더 복잡한 경우가 작동하지 않을 때 정말 혼란스러워하거나 as unknown as Events.Pause 와 같은 해킹에 의존하는 것에 대해 걱정합니다.

옵션 2의 동작을 얻으 려고 시도 하는 많은 방법이 이미 있습니다. 이 스레드에는 많은 스니펫이 있고 문자열 리터럴 통합과 관련된 다양한 접근 방식이 있습니다. 옵션 1을 구현할 때 가장 큰 걱정은 옵션 2를 얻는 또 다른 잘못된 방법을 효과적으로 도입하여 TypeScript의 이 부분을 배우는 사람들에게 더 많은 문제 해결과 좌절을 초래한다는 것입니다.

사람들은 어떤 행동을 원하며 그 이유는 무엇입니까?

코드는 단어보다 더 크게 말하고 OP의 예를 사용하기 때문에:

const BasicEvents = {
    Start: "Start",
    Finish: "Finish"
};
enum AdvEvents {
    ...BasicEvents,
    Pause = "Pause", // We added a new field
    Finish = "Finish2" // Oops, we actually modified a field in the parent enum
};
// The TypeScript compiler should refuse to compile this code
// But after removing the "Finish2" line,
// the TypeScript compiler should successfully handle it as one would normally expect with the spread operator

이 예는 옵션 2를 보여줍니다. 맞죠? 그렇다면 옵션 2를 간절히 원합니다.

그렇지 않으면 우리는 다른 문자열 열거형처럼 작동하지 않는 새로운 종류의 문자열 열거형을 만들고 있습니다. 이는 이상하고 여기 제안의 "단순함"을 손상시키는 것 같습니다

나는 옵션 2가 약간 불안하고 한발 물러서서 대안을 생각하는 것이 최선일 수 있다는 데 동의합니다. 다음은 오늘날의 열거형에 새로운 구문이나 동작을 추가하지 않고 수행할 수 있는 방법에 대한 탐색입니다.

https://github.com/microsoft/TypeScript/issues/17592#issuecomment -449440944의 내 제안이 요즘 가장 가깝고 해결해야 할 사항일 수 있다고 생각합니다.

type Events = BasicEvents | AdvEvents;
const Events = {...BasicEvents, ...AdvEvents};

저는 그 접근 방식에 두 가지 주요 문제가 있다고 봅니다.

• TypeScript를 배우는 사람에게는 정말 혼란스럽습니다. 유형 공간과 값 공간에 대한 확실한 이해가 없다면 상수로 유형을 덮어쓰는 것처럼 보입니다.
• Events.Pause 를 유형으로 사용할 수 없기 때문에 불완전합니다.

나는 이전에 두 번째 글머리 기호를 다룰 https://github.com/microsoft/TypeScript/issues/29130 을 제안했으며 (무엇보다도) 두 번째 글머리 기호를 해결할 수 있지만 여전히 가치가 있을 수 있다고 생각합니다. 이름이 작동하는 방식.

두 가지 점을 모두 다룰 것이라고 생각하는 한 가지 구문 아이디어는 유형도 선언하는 대체 const 구문입니다.

// Declares a value and a type at the same time with the same name (just like `enum` and `class` already do).
// Requires the right-hand side to be either a unit type or an object where all values are unit types.
// The JS emit would just take out the word "type" and leave everything else.
const type Events = {...BasicEvents, ...AdvEvents};
...
const e: Events.Pause = Events.Pause;
...
// The syntax could also make this pattern more ergonomic.
const type INACCESSIBLE = "INACCESSIBLE";
const response: {name: string, favoriteColor: string} | INACCESSIBLE = INACCESSIBLE;

이것은 열거형이 전혀 필요하지 않은 세계에 더 가까워질 것입니다. (나에게 열거형은 기본적으로 사소하지 않은 방출 동작과 명목형을 포함하는 표현식 수준 구문이기 때문에 항상 TS 설계 목표에 어긋나는 것처럼 느껴졌습니다.) const type 선언 구문을 사용하면 다음을 수행할 수도 있습니다. 다음과 같이 구조적으로 유형이 지정된 문자열 열거형을 만듭니다.

const type BasicEvents = {
  Start: 'Start',
  Finish: 'Finish',
};  // "as const" would be implicit for "const type" declarations.

분명히 이것이 작동해야 하는 방식은 BasicEvents 유형이 $# typeof BasicEvents[keyof typeof BasicEvents] 의 약식이라는 것입니다. 이는 const type 와 같은 일반적으로 명명된 구문에 너무 집중될 수 있습니다. 다른 키워드가 더 나을 수도 있습니다. const enum 이(가) 이미 사용 중이여서 아쉽습니다 😛.

거기에서 (문자열) 열거형과 개체 리터럴 사이의 유일한 간격은 명목형 입력이라고 생각합니다. as unique 또는 const unique type 와 같은 구문을 사용하여 이러한 개체 유형에 대해 기본적으로 열거형과 같은 명목형 타이핑 동작을 선택하고 이상적으로는 일반 문자열 상수에 대해서도 이 문제를 해결할 수 있습니다. 또한 Events 를 정의할 때 옵션 1과 옵션 2 사이에서 명확한 선택을 할 수 있습니다. Events 를 완전히 고유한 유형(옵션 1)으로 만들려는 경우 unique 를 사용합니다. Events 와 BasicEvents (옵션 2) 사이의 할당 가능성을 원할 때 unique 를 생략합니다.

const type 및 const unique type 를 사용하면 기존 열거형을 깔끔하게 통합하는 방법과 열거형을 일회성이 아닌 TS 기능의 자연스러운 조합으로 표현하는 방법이 있습니다.

무슨 일이야? 😂

와우 2017년 🤪, 무슨 피드백이 더 필요할까요?

어떤 피드백이 더 필요합니까?

바로 여기에??? 제안이 오래되었다고 해서 제안을 구현하는 것은 아닙니다!

어떤 피드백이 더 필요합니까?

바로 여기에??? 제안이 오래되었다고 해서 제안을 구현하는 것은 아닙니다!

네. 어떤 방식인지 확신이 서지 않았습니다.

다시 읽고 또 보고 #40998 그게 최선의 방법이라고 생각합니다... emun은 객체이고 스프레드는 enum을 병합/확장하기가 더 쉽다고 생각합니다.

언어 디자인에 대한 의견을 제시할 수 있는 자격은 없지만 일반 개발자로서 피드백을 줄 수 있다고 생각합니다.

이 기능을 사용하려는 실제 프로젝트에서 몇 주 전에 이 문제를 접했습니다. @alangpierce 의 접근 방식 을 사용 하게 되었습니다 . 불행히도 고용주에 대한 책임 때문에 여기에서 코드를 공유할 수 없지만 몇 가지 사항은 다음과 같습니다.

1. 반복 선언(새 열거형의 경우 type 및 const 모두)은 큰 문제가 아니며 가독성을 크게 손상시키지 않았습니다.
2. 필자의 경우 enum은 특정 알고리즘에 대해 서로 다른 동작을 나타내었고 이 알고리즘에는 다양한 상황에 대해 서로 다른 동작 세트가 있었습니다. 유형 계층을 사용하여 특정 작업이 컴파일 시간에 발생할 수 없음을 확인할 수 있었습니다. 이것이 전체의 요점이었고 매우 유용한 것으로 판명되었습니다.
3. 내가 작성한 코드는 내부 라이브러리였으며, 라이브러리 내부에서는 서로 다른 enum 유형을 구분하는 것이 중요했지만 이 라이브러리의 외부 사용자에게는 중요하지 않았습니다. 이 접근 방식을 사용하여 내부에 있는 모든 다른 열거형의 합계 유형인 하나의 유형만 내보내고 구현 세부 정보를 숨길 수 있었습니다.
4. 불행히도 나는 형식 선언에서 자동으로 합계 형식의 값을 구문 분석하는 관용적이고 읽기 쉬운 방법을 알아낼 수 없었습니다. (제 경우에는 내가 언급한 다른 알고리즘 단계가 런타임에 SQL 데이터베이스에서 로드되었습니다). 그것은 큰 문제가 아니었지만(파싱 코드를 수동으로 작성하는 것은 충분히 간단했습니다), 열거형 상속의 구현이 이 문제에 약간의 주의를 기울인다면 좋을 것입니다.

전반적으로 지루한 비즈니스 로직을 가진 많은 실제 프로젝트가 이 기능을 통해 많은 이점을 얻을 수 있다고 생각합니다. 열거형을 다른 하위 유형으로 분할하면 유형 시스템이 현재 단위 테스트에서 확인하는 많은 불변량을 확인할 수 있으며 유형 시스템에서 잘못된 값을 표현할 수 없도록 만드는 것은 항상 좋은 일입니다.

안녕,

여기에 내 2센트를 추가하겠습니다 🙂

내 컨텍스트

tsoa 로 생성된 OpenApi 문서와 함께 API가 있습니다.

내 모델 중 하나에 다음과 같이 정의된 상태가 있습니다.

enum EntityStatus {
    created = 'created',
    started = 'started',
    paused = 'paused',
    stopped = 'stopped',
    archived = 'archived',
}

이 상태의 하위 집합을 사용하는 setStatus 메서드가 있습니다. 이 기능을 사용할 수 없기 때문에 열거형을 다음과 같이 복제하는 것을 고려했습니다.

enum RequestedEntityStatus {
    started = 'started',
    paused = 'paused',
    stopped = 'stopped',
}

그래서 내 방법은 다음과 같이 설명됩니다.

public setStatus(status: RequestedEntityStatus) {
   this.status = status;
}

해당 코드를 사용하면 다음 오류가 발생합니다.

Conversion of type 'RequestedEntityStatus' to type 'EntityStatus' may be a mistake because neither type sufficiently overlaps with the other. If this was intentional, convert the expression to 'unknown' first.

지금은 할 것이지만 이것을 찾았을 때 호기심이 생겨 이 저장소를 검색하기 시작했습니다.
아래로 스크롤한 후 이 사용 사례를 제안하는 사람을 찾지 못했습니다.

내 사용 사례에서는 EntityStatus가 RequestedEntityStatus의 확장일 이유가 없기 때문에 열거형에서 "확장"하고 싶지 않습니다. 보다 일반적인 열거형에서 "선택"할 수 있기를 바랍니다.

나의 제안

나는 extends 제안보다 스프레드 연산자가 더 낫다는 것을 알았지만 더 나아가 다음을 제안하고 싶습니다.

enum EntityStatus {
    created = 'created',
    started = 'started',
    paused = 'paused',
    stopped = 'stopped',
    archived = 'archived',
}

enum RequestedEntityStatus {
    // Pick/Reuse from EntityStatus
    EntityStatus.started,
    EntityStatus.paused,
    EntityStatus.stopped,
}

// Fake enum, just to demonstrate
enum TargetStatus {
    {...RequestedEntityStatus},
    // Why not another spread here?
    //{...AnotherEnum},
    EntityStatus.archived,
}

public class Entity {
    private status: EntityStatus = 'created'; // Why not a cast here, if types are compatible, and deserializable from a JSON. EntityStatus would just act as a type union here.

    public setStatus(requestedStatus: RequestedEntityStatus) {
        if (this.status === (requestedStatus as EntityStatus)) { // Should be OK because types are compatible, but the cast would be needed to avoid comparing oranges and apples
            return;
        }

        if (requestedStatus == RequestedStatus.stopped) { // Should be accessible from the enum as if it was declared inside.
            console.log('Stopping...');
        }

        this.status = requestedStatus;// Should work, since EntityStatus contains all the enum members that RequestedEntityStatus has.
    }

    public getStatusAsStatusRequest() : RequestedEntityStatus {
        if (this.status === EntityStatus.created || this.status === EntityStatus.archived) {
            throw new Error('Invalid status');
        }
        return this.status as RequestedEntityStatus; // We have  eliminated the cases where the conversion is impossible, so the conversion should be possible now.
    }
}

더 일반적으로 다음과 같이 작동해야 합니다.

enum A { a = 'a' }
enum B { a = 'a' }

const a:A = A.a;
const b:B = B.a;

console.log(a === b);// Should not say "This condition will always return 'false' since the types 'A' and 'B' have no overlap.". They do have overlaps

다시 말해

불투명 구조보다 통합( 'a' | 'b' )처럼 작동하도록 열거형 유형에 대한 제약을 완화하고 싶습니다.

컴파일러에 이러한 능력을 추가하면 동일한 값을 가진 두 개의 독립적인 열거형을 공용체와 동일한 규칙으로 서로 할당할 수 있습니다.
다음 열거형이 주어지면:

enum A { a = 'a', b = 'b' }
enum B { a = 'a' , c = 'c' }
enum C { ...A, c = 'c' }

그리고 세 개의 변수 a:A , b:B 및 c:C

• A는 C의 하위 집합일 뿐이므로 A의 모든 값은 C의 유효한 값이므로 c = a 가 작동해야 합니다.
• B는 C의 유효한 값인 'a' | 'c' 이므로 c = b 가 작동해야 합니다.
• $# a 가 'b' 와 다른 것으로 알려진 경우 $ b = a 가 작동할 수 있습니다( 'a' 유형에만 해당).
• a = b , 마찬가지로 b 가 'c' 와 다른 것으로 알려진 경우 작동할 수 있습니다.
• b = c 는 c 가 'b' 와 다른 것으로 알려진 경우 작동할 수 있습니다( 'a'|'c' , 정확히 B가 무엇인지 같음)

아니면 평등 비교와 같이 오른쪽에 명시적 캐스트가 필요할까요?

열거형 멤버 충돌 정보

나는 스프레드 연산자가 자연스럽게 느껴지더라도 "마지막 승" 규칙의 팬이 아닙니다.
키와 값이 모두 동일하지 않는 한 열거형의 "키" 또는 "값"이 중복되면 컴파일러는 오류를 반환해야 한다고 말하고 싶습니다.

enum A { a = 'a', b = 'b' }
enum B { a = 'a' , c = 'c' }
enum C {...A, ...B } // OK, equivalent to enum C { a = 'a', b = 'b', c = 'c' }, a is deduplicated
enum D {...A, a = 'd' } // Error : Redefinition of a
enum E {...A, d = 'a' } // Error : Duplicate key with value 'a'

폐쇄

나는 이 제안이 enum이 무엇인지 실제로 변경하지 않고 더 많은 유형 안전성( as unknown as T 와 비교)을 허용하면서 TS 개발자가 작업하기에 매우 유연하고 자연스럽다는 것을 알았습니다. 열거형에 멤버를 추가하는 새로운 방법과 열거형을 서로 비교하는 새로운 방법을 소개합니다.
어떻게 생각해? 이 기능을 사용할 수 없게 만드는 명백한 언어 아키텍처 문제를 놓쳤습니까?