बस इसके साथ थोड़ा सा खेला और वर्तमान में विस्तारित प्रकार के लिए किसी ऑब्जेक्ट का उपयोग करके इस एक्सटेंशन को करना संभव है , इसलिए इसे ठीक काम करना चाहिए:

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 enums का उपयोग कर रहे हैं, तो यह शायद ठीक है। अन्यथा, यह आपके उपयोग के मामले के लिए पर्याप्त नहीं हो सकता है।

हमें दृढ़ता से टाइप किए गए Redux रिड्यूसर के लिए इस सुविधा की आवश्यकता है। कृपया इसे टाइपस्क्रिप्ट में जोड़ें।

एक और समाधान है कि एनम का उपयोग न करें, लेकिन कुछ ऐसा उपयोग करें जो एक एनम जैसा दिखता है:

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];

सभी वर्कअराउंड अच्छे हैं लेकिन मैं टाइपस्क्रिप्ट से ही एनम इनहेरिटेंस सपोर्ट देखना चाहूंगा ताकि मैं यथासंभव सरल चेक का उपयोग कर सकूं।

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+ लोग जिन्होंने सक्रिय रूप से इस सुविधा की खोज की और मांग की - यह बिना दिमाग के लगता है।

यहां तक ​​​​कि एक नाम स्थान में एक अलग फ़ाइल से एनम को फिर से निर्यात करना वास्तव में एनम को विस्तारित किए बिना अजीब है (और एनम को इस तरह से फिर से निर्यात करना असंभव है कि यह अभी भी एनम है और ऑब्जेक्ट और टाइप नहीं है):

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
वर्तमान में वर्कअराउंड का उपयोग कर रहा है, लेकिन यह एक देशी एनम फीचर होना चाहिए।

मैंने इस मुद्दे के माध्यम से यह देखने के लिए स्किम किया कि क्या किसी ने निम्नलिखित प्रश्न उठाया है। (लगता तो नही देता।)

ओपी से:

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 { ।

उस नोट पर, मुझे इसके लिए ओपी से प्रसार का सुझाव पसंद आया।

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

एनम का विस्तार टाइपस्क्रिप्ट की मुख्य विशेषता होनी चाहिए। मैं तो बस कह रहा हूं'

@wottpal मेरे प्रश्न को पहले से दोहरा रहा है:

यदि [enums को बढ़ाया जा सकता है], तो यह जाल इस तथ्य के साथ कितना अच्छा है कि enum प्रकार अंतिम होने के लिए हैं और विस्तार करना संभव नहीं है?

विशेष रूप से, मुझे ऐसा लगता है कि एक एनम वैल्यू पर स्विच स्टेटमेंट की समग्रता जांच एनम की गैर-विस्तारता पर निर्भर करती है।

@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 ) अधिक है? फिर, हाँ, स्विच ठीक निकलते हैं।

हालाँकि, वहाँ _some_ अपेक्षा है जो अभी भी मुझे टूटी हुई लगती है। कोशिश करने और इसे कम करने के तरीके के रूप में: कक्षाओं के साथ, extends नकल शब्दार्थ को _not_ व्यक्त करता है - फ़ील्ड और विधियों को विस्तारित उपवर्ग में कॉपी नहीं किया जाता है; इसके बजाय, उन्हें केवल प्रोटोटाइप श्रृंखला के माध्यम से उपलब्ध कराया जाता है। सुपरक्लास में केवल एक ही क्षेत्र या विधि होती है।

इस वजह से, यदि class B extends A , तो हमें गारंटी दी जाती है कि B को A पर असाइन किया जा सकता है, और इसलिए उदाहरण के लिए let a: A = new B(); बिल्कुल ठीक होगा।

लेकिन enums और extends के साथ, हम let a: A = B.b; नहीं कर पाएंगे, क्योंकि ऐसी कोई गारंटी नहीं है। जो मुझे अजीब लगता है; extends यहां क्या किया जा सकता है, इसके बारे में मान्यताओं का एक निश्चित सेट बताता है, और वे एनम से नहीं मिलते हैं।

फिर बस इसे expands या clones कह रहे हैं? ‍♂️
एक उपयोगकर्ता के नजरिए से यह सिर्फ अजीब लगता है कि जो कुछ बुनियादी है उसे हासिल करना सीधा नहीं है।

यदि उचित शब्दार्थ के लिए एक नया कीवर्ड (अन्य भाषाओं में बहुत अधिक पूर्व कला के बिना) की आवश्यकता है, तो इसके बजाय ओपी और इस टिप्पणी में सुझाए गए स्प्रेड सिंटैक्स ( ... ) का पुन: उपयोग क्यों न करें?

+1 मुझे आशा है कि इसे डिफॉल्ट एन्यूमरेशन फीचर में जोड़ा जाएगा। :)

क्या किसी को कोई सुरुचिपूर्ण समाधान पता है ??? मैं

यदि उचित शब्दार्थ के लिए एक नया कीवर्ड (अन्य भाषाओं में बहुत अधिक पूर्व कला के बिना) की आवश्यकता होती है, तो इसके बजाय ओपी और इस टिप्पणी में सुझाए गए स्प्रेड सिंटैक्स (...) का पुन: उपयोग क्यों नहीं किया जाता है?

हां, इसके बारे में थोड़ा और सोचने के बाद मुझे लगता है कि यह समाधान अच्छा होगा।

इस पूरे अंक को पढ़ने के बाद, ऐसा लगता है कि एक व्यापक समझौता है कि स्प्रेड ऑपरेटर का पुन: उपयोग करने से समस्या हल हो जाती है, और लोगों ने सिंटैक्स को भ्रमित/अनपेक्षित बनाने के बारे में सभी चिंताओं को संबोधित किया है।

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

क्या इस मुद्दे को वास्तव में अभी भी इस बिंदु पर "अधिक प्रतिक्रिया की प्रतीक्षा" लेबल की आवश्यकता है, @RyanCavanaugh ?

सुविधा +1 . चाहती थी

क्या हमारे पास इस मुद्दे पर कोई खबर है? यह वास्तव में उपयोगी लगता है कि प्रसार ऑपरेटर को एनम के लिए लागू किया गया है।

विशेष रूप से उन मामलों का उपयोग करने के लिए जिनमें मेटाप्रोग्रामिंग को उपनाम और विस्तार करने की क्षमता शामिल है, कहीं न कहीं एक होना चाहिए और एक अच्छा होना चाहिए। वर्तमान में एक एनम और export को दूसरे नाम से लेने का कोई तरीका नहीं है - जब तक कि आप ऊपर बताए गए वर्कअराउंड में से किसी एक का सहारा नहीं लेते।

@ m93a आह, तो आपका मतलब है कि extends यहाँ प्रभाव में एक _copying_ शब्दार्थ (एनम मानों का A से B ) अधिक है? फिर, हाँ, स्विच ठीक निकलते हैं।

हालाँकि, वहाँ _some_ अपेक्षा है जो अभी भी मुझे टूटी हुई लगती है। कोशिश करने और इसे कम करने के तरीके के रूप में: कक्षाओं के साथ, extends नकल शब्दार्थ को _not_ व्यक्त करता है - फ़ील्ड और विधियों को विस्तारित उपवर्ग में कॉपी नहीं किया जाता है; इसके बजाय, उन्हें केवल प्रोटोटाइप श्रृंखला के माध्यम से उपलब्ध कराया जाता है। सुपरक्लास में केवल एक ही क्षेत्र या विधि होती है।

इस वजह से, यदि class B extends A , तो हमें गारंटी दी जाती है कि B को A पर असाइन किया जा सकता है, और इसलिए उदाहरण के लिए let a: A = new B(); बिल्कुल ठीक होगा।

लेकिन enums और extends के साथ, हम let a: A = B.b; नहीं कर पाएंगे, क्योंकि ऐसी कोई गारंटी नहीं है। जो मुझे अजीब लगता है; extends यहां क्या किया जा सकता है, इसके बारे में मान्यताओं का एक निश्चित सेट बताता है, और वे एनम से नहीं मिलते हैं।

@masak मुझे लगता है कि आप सही करने के करीब हैं लेकिन आपने एक छोटी सी धारणा बनाई है जो गलत है। बी enum B extends A की स्थिति में "असाइन करने योग्य" के रूप में ए को असाइन करने योग्य है, इसका मतलब है कि ए द्वारा प्रदान किए गए सभी मूल्य बी में उपलब्ध हैं। जब आपने कहा कि let a: A = B.b आप मान रहे हैं कि बी में मान होना चाहिए A में उपलब्ध है, जो A को असाइन किए जाने वाले मानों के समान नहीं है। let a: A = B.a IS सही है क्योंकि 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`

टाइपस्क्रिप्ट खेल का मैदान लिंक

लंबी कहानी छोटी, मेरा मानना ​​​​है कि आईएस सही शब्दावली का विस्तार करता है क्योंकि ठीक यही किया जा रहा है। enum B extends A उदाहरण में आप हमेशा बी एनम से ए एनम के सभी संभावित मूल्यों को शामिल करने की उम्मीद कर सकते हैं, क्योंकि बी ए का "उपवर्ग" (उपवर्ग? शायद इसके लिए एक बेहतर शब्द है) और इस प्रकार ए को सौंपे जाने योग्य

इसलिए मुझे नहीं लगता कि हमें एक नए कीवर्ड की आवश्यकता है, मुझे लगता है कि हमें विस्तार का उपयोग करना चाहिए और मुझे लगता है कि यह मूल रूप से टाइपस्क्रिप्ट का एक हिस्सा होना चाहिए: डी

@ जूलियन-एसएफ मुझे लगता है कि मैं आपके द्वारा लिखी गई हर बात से सहमत हूं ...

...लेकिन...:थोड़ा_मुस्कुराता_चेहरा:

जैसा कि मैंने यहाँ समस्याग्रस्त किया है, इस स्थिति के बारे में क्या?

// 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 _extends_ BasicEvents , क्या आप Pause के BasicEvents का _instance_ होने की भी अपेक्षा करेंगे

दूसरी ओर, एनम (आईएमएचओ) का मूल मूल्य प्रस्ताव यह है कि वे _बंद_/"अंतिम" (जैसा कि, गैर-एक्स्टेंसिबल) हैं ताकि switch कथन जैसा कुछ समग्रता ग्रहण कर सके। (और इसलिए AdvEvents _extend_ करने में सक्षम होने के कारण BasicEvent #$ होने का क्या अर्थ है, enums के लिए किसी प्रकार के कम आश्चर्य का उल्लंघन करता है।)

मुझे नहीं लगता कि आप निम्नलिखित तीन संपत्तियों में से दो से अधिक कर सकते हैं:

• Enums बंद/अंतिम/अनुमानित रूप से कुल
• दो enum घोषणाओं के बीच एक extends संबंध
• (उचित) धारणा है कि यदि b B और B extends A $ का एक उदाहरण है, तो b A #$ का एक उदाहरण है

@masak मैं एनम के बंद प्रिंसिपल (रनटाइम पर) को समझता हूं और सहमत हूं। लेकिन संकलन समय विस्तार रनटाइम पर बंद सिद्धांत का उल्लंघन नहीं करेगा, क्योंकि वे सभी संकलक द्वारा परिभाषित और निर्मित किए जाएंगे।

(उचित) यह धारणा कि यदि b, B का उदाहरण है और B, A का विस्तार करता है, तो b, A का उदाहरण है

मुझे लगता है कि यह तर्क भ्रामक है क्योंकि उदाहरण/वर्ग द्विभाजन वास्तव में एनम के लिए असाइन करने योग्य नहीं है। Enums वर्ग नहीं हैं और उनके पास उदाहरण नहीं हैं। हालांकि, मुझे लगता है कि अगर ठीक से किया जाए तो वे एक्स्टेंसिबल हो सकते हैं। सेट की तरह अधिक एनमों के बारे में सोचें। इस उदाहरण में, B, A का सुपरसेट है। इसलिए यह मान लेना उचित है कि A में कोई भी मान B में मौजूद है, लेकिन A में केवल B के कुछ मान मौजूद होंगे।

मैं समझता हूं कि चिंता कहां से आती है...हालांकि। और मुझे यकीन नहीं है कि इसके बारे में क्या करना है। Enum एक्सटेंशन के साथ किसी समस्या का एक अच्छा उदाहरण:

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 को काफी आसानी से कास्ट कर पाएंगे, लेकिन यह स्पष्ट रूप से यहां काम नहीं करेगा। मुझे जरूरी नहीं लगता कि यह खराब है, मुझे लगता है कि इसका सिर्फ हिसाब होना चाहिए। आईई, आप एक वर्ग की तरह अपने विरासत पेड़ में एक एनम प्रकार को ऊपर की तरफ नहीं लगा सकते हैं। इसे "सुपरसेट एनम बी को ए असाइन नहीं किया जा सकता है, क्योंकि बी के सभी मान ए में मौजूद नहीं हैं" की तर्ज पर एक कंपाइलर त्रुटि के लिए जिम्मेदार ठहराया जा सकता है।

@ जूलियन-एसएफ

मुझे लगता है कि यह तर्क भ्रामक है क्योंकि उदाहरण/वर्ग द्विभाजन वास्तव में एनम के लिए असाइन करने योग्य नहीं है। Enums वर्ग नहीं हैं और उनके पास उदाहरण नहीं हैं।

आप बिल्कुल सही कह रहे हैं, इसके चेहरे पर।

• एक स्वतंत्र भाषा निर्माण के रूप में देखा गया, एक गणना में _members_ होते हैं, उदाहरण नहीं। "सदस्य" शब्द का प्रयोग हैंडबुक और भाषा विशिष्टता दोनों द्वारा किया जाता है। (सी # और पायथन समान रूप से "सदस्य" शब्द का उपयोग करते हैं। जावा "एनम स्थिरांक" का उपयोग करता है, क्योंकि "सदस्य" का जावा में एक अतिभारित अर्थ है।)
• एक संकलित-कोड परिप्रेक्ष्य से देखा गया, एक एनम में _properties_ है, दोनों तरीकों से मैपिंग - नाम-से-मान और मान-से-नाम। फिर से, उदाहरण नहीं।

इस बारे में सोचकर, मुझे एहसास हुआ कि मैं जावा के एनम्स पर थोड़ा सा रंगीन हूं। जावा में, एनम मान वस्तुतः उनके एनम प्रकार के उदाहरण हैं। कार्यान्वयन-वार, एक एनम एक वर्ग है जो एनम वर्ग का विस्तार करता है । (आपको इसे मैन्युअल रूप से करने की अनुमति नहीं है, आपको enum कीवर्ड से गुजरना होगा, लेकिन हुड के तहत यही होता है।) इसके बारे में अच्छी बात यह है कि एनम को सभी उपयुक्तता वर्ग मिलते हैं: वे फ़ील्ड, कंस्ट्रक्टर, विधियाँ हो सकती हैं... इस दृष्टिकोण में, एनम सदस्य _are_ उदाहरण हैं। (जेएलएस उतना ही कहता है।)

ध्यान दें कि मैं टाइपस्क्रिप्ट एनम सेमेन्टिक्स में कोई बदलाव प्रस्तावित नहीं कर रहा हूं। विशेष रूप से, मैं यह नहीं कह रहा हूं कि एनम के लिए जावा के मॉडल का उपयोग करने के लिए टाइपस्क्रिप्ट को बदलना चाहिए। मैं _am_ कह रहा हूं कि एनम/एनम सदस्यों के शीर्ष पर एक वर्ग/उदाहरण "समझ" को ओवरले करना शिक्षाप्रद/व्यावहारिक है। "एक एनम _is_ एक वर्ग" या "एक एनम सदस्य _is_ एक उदाहरण" नहीं ... लेकिन समानताएं हैं जो आगे बढ़ती हैं।

क्या समानताएं? सबसे पहले और सबसे महत्वपूर्ण, सदस्यता टाइप करें।

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

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

अंतिम पंक्ति टाइपचेक नहीं करती है, क्योंकि Bar.Z एक Foo नहीं है। फिर, यह _actually_ वर्ग और उदाहरण नहीं है, लेकिन इसे एक ही मॉडल का उपयोग करके _समझा जा सकता है, जैसे कि Foo और Bar वर्ग थे और छह सदस्य उनके संबंधित उदाहरण थे।

(हम इस तर्क के प्रयोजनों के लिए इस तथ्य को अनदेखा करेंगे कि let foo: Foo = 2; भी शब्दार्थिक रूप से कानूनी है, और सामान्य तौर पर, number मान एनम प्रकार के चर के लिए असाइन करने योग्य हैं।)

Enums के पास अतिरिक्त संपत्ति है कि वे _closed_ हैं - क्षमा करें, मुझे इसके लिए एक बेहतर शब्द नहीं पता है - एक बार जब आप उन्हें परिभाषित कर लेते हैं, तो आप उनका विस्तार नहीं कर सकते। विशेष रूप से, एनम घोषणा के अंदर सूचीबद्ध सदस्य _only_ चीजें हैं जो एनम प्रकार के खिलाफ टाइपमैच करते हैं। ("बंद" जैसा कि "बंद-विश्व परिकल्पना" में है।) यह एक महान संपत्ति है क्योंकि आप कुल निश्चितता के साथ सत्यापित कर सकते हैं कि आपके एनम पर switch स्टेटमेंट में सभी मामलों को कवर किया गया है।

एनम पर extends के साथ, यह संपत्ति खिड़की से बाहर चली जाती है।

आप लिखिए,

मैं एनम्स के बंद प्रिंसिपल (रनटाइम पर) को समझता हूं और सहमत हूं। लेकिन संकलन समय विस्तार रनटाइम पर बंद सिद्धांत का उल्लंघन नहीं करेगा, क्योंकि वे सभी संकलक द्वारा परिभाषित और निर्मित किए जाएंगे।

मुझे नहीं लगता कि यह सच है, क्योंकि यह मानता है कि आपके एनम का विस्तार करने वाला कोई भी कोड आपके प्रोजेक्ट में है। लेकिन एक तृतीय-पक्ष मॉड्यूल आपके एनम का विस्तार कर सकता है, और अचानक _new_ एनम सदस्य होते हैं जो आपके द्वारा संकलित कोड के नियंत्रण के बाहर, आपके एनम को भी असाइन करने योग्य होते हैं। अनिवार्य रूप से, एनम अब बंद नहीं होंगे, संकलन-समय पर भी नहीं।

मुझे अभी भी लगता है कि मैं अपने मतलब को व्यक्त करने में कुछ अनाड़ी हूं, लेकिन मेरा मानना ​​​​है कि यह महत्वपूर्ण है: extends enum पर एनम की सबसे कीमती विशेषताओं में से एक को तोड़ देगा, तथ्य यह है कि वे ' फिर से बंद। कृपया इस कारण से गणना करें कि कितनी भाषाएं पूरी तरह से _forbid_ एक एनम का विस्तार/उप-वर्गीकरण कर रही हैं।

मैंने वर्कअराउंड के बारे में थोड़ा और सोचा, और #17592 (टिप्पणी) से काम करते हुए, आप मूल्य स्थान में 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 चाहिए। आप _can_ typeof Events.Pause का उपयोग करते हैं और यह AdvEvents.Pause के लिए हल हो जाता है, हालांकि मेरी टीम के लोग उस तरह के पैटर्न से भ्रमित हो गए हैं और मुझे लगता है कि व्यवहार में मैं AdvEvents.Pause का उपयोग करते समय प्रोत्साहित करूंगा यह एक प्रकार के रूप में।

(यह उस मामले के लिए है जब आप चाहते हैं कि एनम प्रकार अलग-अलग एनमों के बजाय एक-दूसरे के बीच असाइन करने योग्य हों। मेरे अनुभव से, उन्हें असाइन करने योग्य बनाना सबसे आम है।)

मुझे लगता है कि यह अभी हाथ में सबसे साफ समाधान है।

धन्यवाद @alangpierce : +1:

इस पर किसी भी अद्यतन?

@sdwvit मैं मूल लोगों में से एक नहीं हूं, लेकिन मेरे सुविधाजनक बिंदु से, निम्नलिखित वाक्यविन्यास प्रस्ताव (ओपी से, लेकिन उसके बाद दो बार फिर से सुझाव दिया गया) बिना किसी ज्ञात मुद्दों के सभी को खुश कर देगा:

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

यह _me_ को खुश कर देगा, क्योंकि इसका मतलब यह प्रतीत होता है कि यह उपयोगी "इस अन्य एनम में सभी सदस्यों को डुप्लिकेट करें" सुविधा _with_ का उपयोग करके extends का उपयोग कर रहा है, जिसे मैं अपने द्वारा बताए गए कारणों के लिए समस्याग्रस्त मानता हूं। ... सिंटैक्स इन मुद्दों को कॉपी करके टालता है, न कि विस्तार करके।

इस मुद्दे को अभी भी "अधिक प्रतिक्रिया की प्रतीक्षा" के रूप में चिह्नित किया गया है, और जब तक वे आवश्यक महसूस करते हैं, मैं इसे उस श्रेणी में रखने के मुख्य सदस्यों के अधिकार का सम्मान करता हूं। लेकिन साथ ही, उपरोक्त को लागू करने और इसे पीआर के रूप में जमा करने से किसी को रोकने के लिए कुछ भी नहीं है।

@masak प्रतिक्रिया के लिए धन्यवाद। मुझे अब सभी चर्चा इतिहास से गुजरना है। बाद में आपके पास वापस आऊंगा :)

मैं इसे होते हुए देखना बिल्कुल पसंद करूंगा और इसे स्वयं लागू करने का प्रयास करना बिल्कुल पसंद करूंगा। हालाँकि हमें अभी भी सभी एनमों के लिए व्यवहार को परिभाषित करने की आवश्यकता है। यह सब स्ट्रिंग-आधारित एनम के लिए अच्छा काम करता है, लेकिन वेनिला न्यूमेरिक एनम के बारे में क्या। यहां विस्तार/प्रतिलिपि कैसे काम करती है?

• मुझे लगता है कि हम केवल "उसी प्रकार" एनम के साथ एक एनम को विस्तारित करने की अनुमति देना चाहेंगे (संख्यात्मक संख्यात्मक बढ़ाता है, स्ट्रिंग स्ट्रिंग बढ़ाता है)। विषम एनम तकनीकी रूप से समर्थित हैं इसलिए मुझे लगता है कि हमें उस समर्थन को बनाए रखना चाहिए।

• क्या हमें कई एनमों से विस्तार करने की अनुमति देनी चाहिए? क्या उन सभी के परस्पर अनन्य मूल्य होने चाहिए? या हम अतिव्यापी मूल्यों की अनुमति देंगे? शाब्दिक क्रम के आधार पर प्राथमिकता?

• क्या विस्तारित एनम विस्तारित एनमों के मूल्यों को ओवरराइड कर सकते हैं?

• क्या विस्तारित एनम प्रकट होना चाहिए कि मूल्यों की सूची की शुरुआत है या यह किसी भी क्रम में हो सकता है? मुझे लगता है कि बाद में परिभाषित मूल्यों की उच्च प्राथमिकता है?

• मुझे लगता है कि विस्तारित संख्यात्मक enums के अधिकतम मूल्य के बाद निहित संख्यात्मक मान 1 जारी रहेगा।

• बिट-मास्क के लिए विशेष विचार?

आदि आदि।

@JeffreyMercado ये अच्छे प्रश्न हैं, और उन लोगों के लिए उपयुक्त हैं जो कार्यान्वयन का प्रयास करने की उम्मीद करते हैं। :मुस्कुराओ:

नीचे मेरे उत्तर दिए गए हैं, जो एक "रूढ़िवादी" डिज़ाइन दृष्टिकोण द्वारा निर्देशित हैं (जैसा कि "चलो डिज़ाइन निर्णय लेते हैं जो उन मामलों को अस्वीकार करते हैं जिनके बारे में हम निश्चित नहीं हैं, बजाय इसके कि अब ऐसे विकल्प चुनें जिन्हें बाद में पीछे की ओर संगत रहते हुए बदलना मुश्किल हो")।

• मुझे लगता है कि हम केवल "उसी प्रकार" एनम के साथ एक एनम को विस्तारित करने की अनुमति देना चाहेंगे (संख्यात्मक संख्यात्मक बढ़ाता है, स्ट्रिंग स्ट्रिंग बढ़ाता है)

मैं भी ऐसा मानता हूँ। मिश्रित प्रकार का परिणामी एनम अति-उपयोगी नहीं लगता है।

• क्या हमें कई एनमों से विस्तार करने की अनुमति देनी चाहिए? क्या उन सभी के परस्पर अनन्य मूल्य होने चाहिए? या हम अतिव्यापी मूल्यों की अनुमति देंगे? शाब्दिक क्रम के आधार पर प्राथमिकता?

चूंकि यह शब्दार्थ की नकल कर रहा है, जिसके बारे में हम बात कर रहे हैं, कई एनमों की नकल करना मल्टीपल इनहेरिटेंस ए ला सी ++ की तुलना में "अधिक ठीक" लगता है। मुझे इसके साथ तुरंत कोई समस्या नहीं दिखती, खासकर यदि हम ऑब्जेक्ट स्प्रेड के सादृश्य पर निर्माण करते रहें: let newEnum = { ...enumA, ...enumB };

क्या सभी सदस्यों के परस्पर अनन्य मूल्य होने चाहिए? रूढ़िवादी बात "हां" कहना होगा। फिर से, ऑब्जेक्ट स्प्रेड की सादृश्यता हमें एक वैकल्पिक शब्दार्थ प्रदान करती है: अंतिम जीत।

मैं किसी भी उपयोग के मामलों के बारे में नहीं सोच सकता जहां मैं एनम मूल्यों को ओवरराइड करने में सक्षम होने की सराहना करता हूं। लेकिन यह मेरी ओर से कल्पना की कमी हो सकती है। टकरावों को अस्वीकार करने के रूढ़िवादी दृष्टिकोण में सुखद गुण हैं जिन्हें समझाना/आंतरिक बनाना आसान है, और कम से कम सिद्धांत में यह वास्तविक डिज़ाइन त्रुटियों (ताजा कोड में, या कोड जिसे बनाए रखा जा रहा है) का पर्दाफाश कर सकता है।

• क्या विस्तारित एनम विस्तारित एनमों के मूल्यों को ओवरराइड कर सकते हैं?

मुझे लगता है कि उत्तर और तर्क इस मामले में पिछले मामले की तरह ही हैं।

• क्या विस्तारित एनम प्रकट होना चाहिए कि मूल्यों की सूची की शुरुआत है या यह किसी भी क्रम में हो सकता है? मुझे लगता है कि बाद में परिभाषित मूल्यों की उच्च प्राथमिकता है?

मैं पहले यह कहने जा रहा था कि यह केवल तभी मायने रखता है जब हम ओवरराइडिंग के "आखिरी एक जीत" अर्थशास्त्र के साथ जाते हैं।

लेकिन दूसरे विचार पर, "कोई टकराव नहीं" और "आखिरी एक जीत" दोनों के तहत, मुझे सूची में फैलाने से पहले एनम सदस्य घोषणाओं को रखने के लिए _want_ भी अजीब लगता है। जैसे, ऐसा करने से किस आशय का संचार किया जा रहा है? स्प्रेड कुछ हद तक "आयात" की तरह होते हैं, और ये पारंपरिक रूप से शीर्ष पर जाते हैं।

मैं अनिवार्य रूप से एनम सदस्य घोषणाओं के बाद एनम स्प्रेड डालने से मना नहीं करना चाहता (हालांकि मुझे लगता है कि व्याकरण में इसकी अनुमति नहीं होने के साथ मैं ठीक होगा)। यदि इसकी अनुमति समाप्त हो जाती है, तो यह निश्चित रूप से कुछ ऐसा है जिसे लिंटर और सामुदायिक सम्मेलन टालने योग्य बता सकते हैं। ऐसा करने का कोई ठोस कारण नहीं है।

• मुझे लगता है कि विस्तारित संख्यात्मक enums के अधिकतम मूल्य के बाद निहित संख्यात्मक मान 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 यह enums का एक अच्छा उपयोग है, लेकिन ... मैं यह देखने में असफल रहा कि यह मौजूदा enum को विस्तारित करने के रूप में कैसे गिना जाता है। आप जो कर रहे हैं वह _using_ एनम है।

(इसके अलावा, एनम और स्विच स्टेटमेंट के विपरीत, ऐसा लगता है कि आपके उदाहरण में आपके पास कोई समग्रता जाँच नहीं है; कोई व्यक्ति जिसने बाद में एक एनम सदस्य जोड़ा है, वह आसानी से SINGULAR और PLURAL में संबंधित कुंजी जोड़ना भूल सकता है। Label के सभी उदाहरणों में PLURAL रिकॉर्ड।)

@masak

कोई व्यक्ति जिसने बाद में एक एनम सदस्य जोड़ा है, वह आसानी से SINGULAR और PLURAL रिकॉर्ड में संबंधित कुंजी जोड़ना भूल सकता है $#$2 Label #$ के सभी उदाहरणों में।)

कम से कम मेरे वातावरण में, यह एक त्रुटि फेंकता है जब एक एनम सदस्य SINGULAR या PLURAL से गायब है। मुझे लगता है कि Record प्रकार अपना काम करता है।

जबकि TS के लिए प्रलेखन अच्छा है, मुझे लगता है कि कई विशेषताओं को एक साथ एक गैर-तुच्छ तरीके से कैसे संयोजित किया जाए, इसके कई उदाहरण नहीं हैं। enum inheritance जब मैंने अंतर्राष्ट्रीयकरण की समस्याओं को हल करने की कोशिश की, तो मैंने पहली बार देखा, जिससे यह धागा सामने आया। वैसे भी तरीका गलत निकला, यही वजह है कि मैंने यह पोस्ट लिखी है।

@illeatmyhat

कम से कम मेरे वातावरण में, यह एक त्रुटि फेंकता है जब एक एनम सदस्य SINGULAR या PLURAL से गायब है। मुझे लगता है कि Record प्रकार अपना काम करता है।

ओह! टीआईएल। और हाँ, यह इसे और अधिक रोचक बनाता है। मैं देखता हूं कि शुरुआत में एनम विरासत तक पहुंचने और अंततः आपके पैटर्न पर उतरने के बारे में आपका क्या मतलब है। यह एक अलग बात भी नहीं हो सकती है; "एक्स/वाई समस्याएं" एक वास्तविक चीज हैं। अधिक लोग इस विचार से शुरू कर सकते हैं कि "मैं MyEnum का विस्तार करना चाहता हूं", लेकिन अंत में आप की तरह Record<MyEnum, string> का उपयोग कर रहे हैं।

@masak का जवाब :

Enums पर विस्तार के साथ, यह संपत्ति खिड़की से बाहर जाती है।

आप लिखिए,

@ जूलियन-एसएफ: मैं एनम के बंद प्रिंसिपल (रनटाइम पर) को समझता हूं और सहमत हूं। लेकिन संकलन समय विस्तार रनटाइम पर बंद सिद्धांत का उल्लंघन नहीं करेगा, क्योंकि वे सभी संकलक द्वारा परिभाषित और निर्मित किए जाएंगे।

मुझे नहीं लगता कि यह सच है, क्योंकि यह मानता है कि आपके एनम का विस्तार करने वाला कोई भी कोड आपके प्रोजेक्ट में है। लेकिन एक तृतीय-पक्ष मॉड्यूल आपके एनम का विस्तार कर सकता है, और अचानक नए एनम सदस्य होते हैं जो आपके द्वारा संकलित कोड के नियंत्रण के बाहर, आपके एनम को भी असाइन करने योग्य होते हैं। अनिवार्य रूप से, एनम अब बंद नहीं होंगे, संकलन-समय पर भी नहीं।

जितना अधिक मैं इसके बारे में सोचता हूं, आप बिल्कुल सही हैं। एनम बंद होना चाहिए। मुझे वास्तव में "रचना" के विचार पसंद हैं क्योंकि मुझे लगता है कि यह वास्तव में उस मामले का दिल है जो हम यहां चाहते हैं ।

मुझे लगता है कि यह संकेतन "एक साथ सिलाई" की अवधारणा को दो अलग-अलग एनमों को काफी सुंदर ढंग से सारांशित करता है:

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

तो विचार करें कि extends . शब्द का उपयोग करने पर मेरा इस्तीफा

@masak के @JeffreyMercado के सवालों के जवाब पर टिप्पणियाँ:

• मुझे लगता है कि हम केवल "उसी प्रकार" एनम के साथ एक एनम को विस्तारित करने की अनुमति देना चाहेंगे (संख्यात्मक संख्यात्मक बढ़ाता है, स्ट्रिंग स्ट्रिंग बढ़ाता है)। विषम एनम तकनीकी रूप से समर्थित हैं इसलिए मुझे लगता है कि हमें उस समर्थन को बनाए रखना चाहिए।

मैं भी ऐसा मानता हूँ। मिश्रित प्रकार का परिणामी एनम अति-उपयोगी नहीं लगता है।

जबकि मैं मानता हूं कि यह उपयोगी नहीं है, हमें शायद यहां एनमों के लिए विषम समर्थन रखना चाहिए। मुझे लगता है कि एक लिंटर चेतावनी यहां उपयोगी होगी, लेकिन मुझे नहीं लगता कि टीएस को इसके रास्ते में आना चाहिए। मैं एक आकस्मिक उपयोग के मामले के बारे में सोच सकता हूं, जो कि, मैं एक बहुत ही खराब डिज़ाइन किए गए एपीआई के साथ बातचीत के लिए एक एनम बना रहा हूं जो झंडे लेता है जो संख्याओं और तारों का मिश्रण होता है। मुझे पता है, लेकिन चूंकि इसकी अनुमति कहीं और है, इसलिए मुझे नहीं लगता कि हमें यहां इसकी अनुमति नहीं देनी चाहिए।

शायद सिर्फ मजबूत प्रोत्साहन नहीं?

• क्या हमें कई एनमों से विस्तार करने की अनुमति देनी चाहिए? क्या उन सभी के परस्पर अनन्य मूल्य होने चाहिए? या हम अतिव्यापी मूल्यों की अनुमति देंगे? शाब्दिक क्रम के आधार पर प्राथमिकता?

चूंकि यह शब्दार्थ की नकल कर रहा है, जिसके बारे में हम बात कर रहे हैं, कई एनमों की नकल करना मल्टीपल इनहेरिटेंस ए ला सी ++ की तुलना में "अधिक ठीक" लगता है। मुझे इसके साथ तुरंत कोई समस्या नहीं दिखाई देती है, खासकर यदि हम ऑब्जेक्ट स्प्रेड के सादृश्य पर निर्माण करना जारी रखते हैं: let newEnum = {...enumA, ...enumB};

100% सहमत

• क्या सभी सदस्यों के परस्पर अनन्य मूल्य होने चाहिए?

रूढ़िवादी बात "हां" कहना होगा। फिर से, ऑब्जेक्ट स्प्रेड की सादृश्यता हमें एक वैकल्पिक शब्दार्थ प्रदान करती है: अंतिम जीत।

मैं यहाँ फटा हुआ हूँ। जबकि मैं मानता हूं कि मूल्यों की पारस्परिक विशिष्टता को लागू करने के लिए यह "सर्वोत्तम अभ्यास" है, क्या यह सही है? यह आमतौर पर ज्ञात प्रसार शब्दार्थ के लिए सीधे विरोधाभासी है। एक ओर, मुझे परस्पर अनन्य मूल्यों को लागू करने का विचार पसंद है, दूसरी ओर, यह बहुत सी धारणाओं को तोड़ता है कि कैसे शब्दार्थ को फैलाना चाहिए। क्या "पिछले एक जीत" के साथ सामान्य प्रसार नियमों का पालन करने में कोई कमी है? ऐसा लगता है कि यह कार्यान्वयन पर आसान है (क्योंकि अंतर्निहित वस्तु वैसे भी एक नक्शा है)। लेकिन यह आम उम्मीदों के अनुरूप भी लगता है। मैं कम आश्चर्यजनक होने की ओर झुक रहा हूं।

किसी मान को ओवरराइड करने के लिए अच्छे उदाहरण भी हो सकते हैं (हालांकि मुझे नहीं पता कि वे क्या होंगे)।

लेकिन दूसरे विचार पर, दोनों "कोई टकराव नहीं" और "आखिरी एक जीत" के तहत, मुझे यह अजीब लगता है कि सूची में एनम फैलाने से पहले एनम सदस्य घोषणाएं भी रखना चाहते हैं। जैसे, ऐसा करने से किस आशय का संचार किया जा रहा है? स्प्रेड कुछ हद तक "आयात" की तरह होते हैं, और ये पारंपरिक रूप से शीर्ष पर जाते हैं।

खैर यह निर्भर करता है, अगर हम प्रसार शब्दार्थ का पालन कर रहे हैं, तो इससे कोई फर्क नहीं पड़ता कि आदेश क्या है। ईमानदारी से, भले ही हम परस्पर अनन्य मूल्यों को लागू कर रहे हों, आदेश वास्तव में मायने नहीं रखता, है ना? आदेश की परवाह किए बिना, उस बिंदु पर टकराव एक त्रुटि होगी।

• मुझे लगता है कि विस्तारित संख्यात्मक enums के अधिकतम मूल्य के बाद निहित संख्यात्मक मान 1 जारी रहेगा।

शायद रूढ़िवादी बात यह है कि प्रसार के बाद पहले सदस्य के लिए एक स्पष्ट मूल्य की आवश्यकता होती है।

मैं सहमत हूं। यदि आप एक एनम फैलाते हैं, तो टीएस को अतिरिक्त सदस्यों के लिए स्पष्ट मूल्यों को लागू करना चाहिए।

@ जूलियन-एसएफ

इसलिए विचार करें कि इस शब्द का उपयोग करने पर मेरा इस्तीफा बढ़ जाता है

:+1: योग प्रकार के संरक्षण के लिए सोसायटी किनारे से जयकार करती है।

लेकिन दूसरे विचार पर, दोनों "कोई टकराव नहीं" और "आखिरी एक जीत" के तहत, मुझे यह अजीब लगता है कि सूची में एनम फैलाने से पहले एनम सदस्य घोषणाएं भी रखना चाहते हैं। जैसे, ऐसा करने से किस आशय का संचार किया जा रहा है? स्प्रेड कुछ हद तक "आयात" की तरह होते हैं, और ये पारंपरिक रूप से शीर्ष पर जाते हैं।

खैर यह निर्भर करता है, अगर हम प्रसार शब्दार्थ का पालन कर रहे हैं, तो इससे कोई फर्क नहीं पड़ता कि आदेश क्या है। ईमानदारी से, भले ही हम परस्पर अनन्य मूल्यों को लागू कर रहे हों, आदेश वास्तव में मायने नहीं रखता, है ना? आदेश की परवाह किए बिना, उस बिंदु पर टकराव एक त्रुटि होगी।

मैं कह रहा हूं "सामान्य सदस्य घोषणाओं के बाद स्प्रेड लगाने का कोई अच्छा कारण नहीं है"; आप कह रहे हैं "उचित प्रतिबंधों के तहत, उन्हें पहले या बाद में रखने से कोई फर्क नहीं पड़ता"। ये दोनों बातें एक ही समय में सच हो सकती हैं।

परिणाम में मुख्य अंतर सामान्य सदस्यों के सामने प्रसार की अनुमति देने या अस्वीकार करने के एक स्पेक्ट्रम पर पड़ता प्रतीत होता है। इसे वाक्यात्मक रूप से अस्वीकृत किया जा सकता है; यह एक लिंटर चेतावनी उत्पन्न कर सकता है; या यह सभी मामलों में पूरी तरह से ठीक हो सकता है। यदि आदेश में कोई अर्थ संबंधी अंतर नहीं है, तो यह एनम स्प्रेड फीचर को कम से कम आश्चर्य के सिद्धांत का पालन करने, उपयोग करने में आसान और सिखाने / समझाने में आसान बनाने के लिए नीचे आता है।

स्प्रेड ऑपरेटर का उपयोग पूरे जेएस और टाइपस्क्रिप्ट में उथली प्रतिलिपि के व्यापक उपयोग में आता है। यह निश्चित रूप से extends का उपयोग करने की तुलना में अधिक व्यापक रूप से उपयोग किया जाने वाला और समझने में आसान तरीका है, जिसका अर्थ प्रत्यक्ष संबंध है। रचना के माध्यम से एक एनम बनाना उपभोग करने का आसान उपाय होगा।

सुझावों के इर्द-गिर्द कुछ काम, जबकि मान्य और प्रयोग करने योग्य, समान वांछित परिणाम प्राप्त करने के लिए बहुत अधिक बॉयलरप्लेट कोड जोड़ते हैं। एक एनम की अंतिम और अपरिवर्तनीय प्रकृति को देखते हुए, अन्य भाषाओं के अनुरूप गुणों को बनाए रखने के लिए, संरचना के माध्यम से अतिरिक्त एनम बनाना वांछनीय होगा।

यह शर्म की बात है कि इस बातचीत पर 3 साल अभी भी चल रहे हैं।

@ jmitchell38488 मैं आपकी टिप्पणी को पसंद करूंगा, लेकिन आपके अंतिम वाक्य ने मेरा विचार बदल दिया। यह एक आवश्यक चर्चा है, क्योंकि प्रस्तावित समाधान काम करेगा, लेकिन यह इस तरह से कक्षाओं और इंटरफेस को विस्तारित करने की संभावना को भी दर्शाता है। यह एक बड़ा बदलाव है जो कुछ c++- जैसे भाषा प्रोग्रामर को टाइपस्क्रिप्ट का उपयोग करने से डरा सकता है, क्योंकि आप मूल रूप से एक ही काम करने के 2 तरीकों ( class A extends B और class A { ...(class B {}) } ) के साथ समाप्त होते हैं। मुझे लगता है, दोनों तरीकों का समर्थन किया जा सकता है, लेकिन फिर हमें extend के साथ-साथ स्थिरता के लिए extend की आवश्यकता है।

@masak wdyt? ^

@sdwvit मैं कक्षाओं और इंटरफेस बनाने के लिए व्यवहार को बदलने के बारे में नहीं ले रहा हूं, मैं विशेष रूप से enums के बारे में बात कर रहा हूं और उन्हें रचना के माध्यम से बना रहा हूं। वे अपरिवर्तनीय अंतिम प्रकार हैं, इसलिए हमें सामान्य विरासत फैशन में विस्तार करने में सक्षम नहीं होना चाहिए।

जेएस की प्रकृति और अंतिम पारदर्शी मूल्य को देखते हुए, ऐसा कोई कारण नहीं है कि रचना प्राप्त नहीं की जा सकती। निश्चित रूप से एनमों के साथ काम करना अधिक आकर्षक होगा।

@masak wdyt? ^

हम्म। मुझे लगता है कि भाषा की निरंतरता एक प्रशंसनीय लक्ष्य है, और इसलिए कक्षाओं और इंटरफेस में समान ... सुविधा के लिए पूछना _a प्राथमिकता_ गलत नहीं है। लेकिन मुझे लगता है कि मामला कमजोर या अस्तित्वहीन है, और दो कारणों से: (ए) कक्षाओं और इंटरफेस में पहले से ही एक विस्तार तंत्र है, और दूसरा जोड़ने से थोड़ा अतिरिक्त मूल्य मिलता है (जबकि एनम के लिए एक प्रदान करना एक उपयोग के मामले को कवर करेगा जो लोग वर्षों से इस मुद्दे पर वापस आ रहे हैं); (बी) कक्षाओं में नया सिंटैक्स और शब्दार्थ जोड़ने से अनुमोदन के लिए बहुत अधिक बार होता है, क्योंकि कक्षाएं कुछ अर्थों में एक्मास्क्रिप्ट विनिर्देश से होती हैं। (टाइपस्क्रिप्ट ES6 से पुराना है, लेकिन पहले वाले को बाद वाले के करीब रखने के लिए एक सक्रिय प्रयास किया गया है। इसमें शीर्ष पर अतिरिक्त सुविधाओं को शामिल नहीं करना शामिल है।)

मुझे लगता है कि यह धागा लंबे समय से खुला है क्योंकि यह एक योग्य विशेषता का प्रतिनिधित्व करता है जो वास्तविक उपयोग के मामलों को कवर करेगा, लेकिन इसके लिए अभी तक पीआर नहीं बनाया गया है। इस तरह के पीआर को बनाने में समय और मेहनत लगती है, सिर्फ यह कहने से ज्यादा कि आपको फीचर चाहिए। :आँख मारना:

क्या कोई इस सुविधा पर काम कर रहा है?

क्या कोई इस सुविधा पर काम कर रहा है?

मेरा अनुमान नहीं है, क्योंकि हमने इस पर चर्चा भी पूरी नहीं की है, हाहा!

मुझे ऐसा लगता है कि हम इस पर आम सहमति के करीब आ गए हैं कि यह कैसा दिखेगा। चूंकि यह एक भाषा जोड़ होगा, इसलिए इस प्रस्ताव को आगे बढ़ाने के लिए शायद "चैंपियन" की आवश्यकता होगी। मुझे लगता है कि टीएस टीम से किसी को आने और इस मुद्दे को "प्रतिक्रिया की प्रतीक्षा" से "प्रस्ताव की प्रतीक्षा" (या कुछ इसी तरह) में स्थानांतरित करने की आवश्यकता होगी।

मैं इसके प्रोटोटाइप पर काम कर रहा हूं। हालांकि मुझे समय की कमी और कोड की संरचना से अपरिचित होने के कारण बहुत दूर नहीं मिला है। मैं इसके माध्यम से देखना चाहता हूं और यदि कोई अन्य आंदोलन नहीं है, तो जब भी मैं कर सकता हूं, मैं इसे जारी रखूंगा।

यह फीचर भी पसंद आएगा। 37 महीने बीत चुके हैं, उम्मीद है कि जल्द ही प्रगति होगी

हाल की बैठक के नोट्स:

• हमें स्प्रेड सिंटैक्स पसंद है, क्योंकि extends एक उपप्रकार का अर्थ है, जबकि एक एनम "विस्तार" एक सुपरटाइप बनाता है।

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

• विचार यह है कि AdvEvents.Start उसी प्रकार की पहचान को हल करेगा जैसे BasicEvents.Start । इसका निहितार्थ यह है कि प्रकार 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 स्ट्रिंग एनम्स की अपारदर्शी गुणवत्ता के कारण एक दूसरे को _not_ असाइन करने योग्य नहीं हैं।

  इस कार्यान्वयन का एक और मामूली परिणाम यह है कि AdvEvents.Start को शायद BasicEvents.Start के रूप में त्वरित जानकारी और घोषणा उत्सर्जन में क्रमबद्ध किया जाएगा (कम से कम जहां सदस्य को AdvEvents से जोड़ने के लिए कोई वाक्य रचनात्मक संदर्भ नहीं है। -शाब्दिक अभिव्यक्ति AdvEvents.Start पर होवर करने से संभावित रूप से त्वरित जानकारी मिल सकती है जो AdvEvents.Start कहती है, लेकिन फिर भी BasicEvents.Start प्रदर्शित करना अधिक स्पष्ट हो सकता है)।

• यह केवल स्ट्रिंग एनम में ही अनुमति दी जाएगी।

मैं इस पर कोशिश करना चाहूंगा।

स्पष्ट करने के लिए: यह कार्यान्वयन के लिए स्वीकृत नहीं है।

यहां दो संभावित व्यवहार हैं, और वे दोनों खराब लगते हैं।

विकल्प 1: यह वास्तव में चीनी है

यदि स्प्रेड वास्तव में फैला हुआ एनम के सदस्यों की प्रतिलिपि बनाने के समान है, तो एक बड़ा आश्चर्य होगा जब लोग विस्तारित एनम के मूल्य का उपयोग करने का प्रयास करेंगे जैसे कि यह विस्तारित एनम का मूल्य था और यह काम नहीं करता है।

विकल्प 2: यह वास्तव में चीनी नहीं है

पसंदीदा विकल्प यह होगा कि स्प्रेड थ्रेड के शीर्ष के पास @ aj-r के संघ प्रकार के सुझाव की तरह अधिक काम करता है। यदि ऐसा व्यवहार लोग पहले से ही चाहते हैं, तो टेबल पर मौजूदा विकल्प समझदारी के लिए सख्ती से बेहतर लगते हैं। अन्यथा हम एक नए प्रकार का स्ट्रिंग एनम बना रहे हैं जो किसी अन्य स्ट्रिंग एनम की तरह व्यवहार नहीं करता है, जो अजीब है और यहां सुझाव की "सरलता" को कमजोर करता है।

लोग कौन सा व्यवहार चाहते हैं, और क्यों?

मुझे विकल्प 1 नहीं चाहिए, क्योंकि यह बड़े आश्चर्य की ओर ले जाता है।

मुझे विकल्प 2 चाहिए, लेकिन मुझे @aj-r उल्लिखित नकारात्मक पक्ष को दूर करने के लिए पर्याप्त वाक्यविन्यास समर्थन प्राप्त करना अच्छा लगेगा, इसलिए मैं उनके उदाहरण से let e: Events = Events.Pause; लिख सकता था। नकारात्मक पक्ष भयानक नहीं है, लेकिन यह एक ऐसी जगह है जहां विस्तारित एनम कार्यान्वयन को छिपा नहीं सकता है; तो यह एक प्रकार का स्थूल है।

मुझे भी लगता है कि विकल्प 1 एक बुरा विचार है। मैंने अपनी कंपनी में इस मुद्दे के संदर्भों की खोज की और दो कोड समीक्षाएं मिलीं जहां यह जुड़ा हुआ था, और दोनों मामलों में (और मेरे व्यक्तिगत अनुभव में), छोटे एनम के तत्वों को बड़े एनम प्रकार के लिए असाइन करने योग्य होने की स्पष्ट आवश्यकता है . मैं विशेष रूप से ... पेश करने वाले एक व्यक्ति के बारे में चिंता करता हूं, यह सोचकर कि यह विकल्प 2 की तरह व्यवहार करता है, और फिर अगला व्यक्ति वास्तव में भ्रमित हो रहा है (या as unknown as Events.Pause जैसे हैक्स का सहारा लेना) जब अधिक जटिल मामले काम नहीं करते हैं।

विकल्प 2 के व्यवहार को प्राप्त करने का प्रयास करने के लिए पहले से ही बहुत सारे तरीके हैं: इस धागे में बहुत सारे स्निपेट, साथ ही स्ट्रिंग शाब्दिक संघों से जुड़े विभिन्न दृष्टिकोण। विकल्प 1 को लागू करने के साथ मेरी बड़ी चिंता यह है कि यह विकल्प 2 प्राप्त करने के लिए प्रभावी रूप से एक और गलत तरीका पेश करता है, और इस प्रकार टाइपस्क्रिप्ट के इस हिस्से को सीखने वाले लोगों के लिए अधिक समस्या निवारण और निराशा होती है।

लोग कौन सा व्यवहार चाहते हैं, और क्यों?

चूंकि कोड शब्दों की तुलना में जोर से बोलता है, और ओपी से उदाहरण का उपयोग करता है:

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

मुझे उस दृष्टिकोण के साथ दो मुख्य समस्याएं दिखाई देती हैं:

• टाइपस्क्रिप्ट सीखने वाले किसी व्यक्ति के लिए यह वास्तव में भ्रमित करने वाला है; यदि आपके पास टाइप स्पेस बनाम वैल्यू स्पेस पर ठोस समझ नहीं है, तो ऐसा लगता है कि यह एक प्रकार को स्थिरांक के साथ ओवरराइट कर रहा है।
• यह अधूरा है क्योंकि यह आपको एक प्रकार के रूप में 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;

यह एक ऐसी दुनिया के करीब पहुंच जाएगा जहां एनम बिल्कुल जरूरी नहीं हैं। (मेरे लिए, एनम्स ने हमेशा महसूस किया है कि वे टीएस डिज़ाइन लक्ष्यों के खिलाफ जाते हैं क्योंकि वे गैर-तुच्छ उत्सर्जन व्यवहार के साथ अभिव्यक्ति-स्तर वाक्यविन्यास हैं और डिफ़ॉल्ट रूप से नाममात्र हैं।) const type घोषणा वाक्यविन्यास भी आपको अनुमति देगा इस तरह एक संरचनात्मक रूप से टाइप की गई स्ट्रिंग एनम बनाएं:

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

बेशक, जिस तरह से इसे काम करने की आवश्यकता होगी वह यह है कि BasicEvents प्रकार BasicEvents typeof BasicEvents[keyof typeof BasicEvents] लिए शॉर्टहैंड है, जो कि const type जैसे सामान्य रूप से नामित वाक्यविन्यास के लिए बहुत अधिक केंद्रित हो सकता है। शायद एक अलग कीवर्ड बेहतर होगा। बहुत बुरा const enum पहले ही लिया जा चुका है .

वहां से, मुझे लगता है कि (स्ट्रिंग) एनम और ऑब्जेक्ट लिटरल्स के बीच एकमात्र अंतर नाममात्र का टाइपिंग होगा। संभवतः इसे as unique या const unique type जैसे सिंटैक्स का उपयोग करके हल किया जा सकता है जो मूल रूप से इन ऑब्जेक्ट प्रकारों के लिए एनम-जैसे नाममात्र टाइपिंग व्यवहार में शामिल होता है, और आदर्श रूप से नियमित स्ट्रिंग स्थिरांक के लिए भी। Events को परिभाषित करते समय यह विकल्प 1 और विकल्प 2 के बीच एक स्पष्ट विकल्प भी देगा: आप unique का उपयोग तब करते हैं जब आप Events को पूरी तरह से अलग प्रकार (विकल्प 1) बनाने का इरादा रखते हैं, और आप unique छोड़ देते हैं जब आप Events और BasicEvents (विकल्प 2) के बीच असाइनमेंट करना चाहते हैं।

const type और const unique type के साथ, मौजूदा एनमों को साफ-सुथरा बनाने का एक तरीका होगा, और एक बार के बजाय टीएस सुविधाओं के प्राकृतिक संयोजन के रूप में एनम को व्यक्त करने का एक तरीका भी होगा।

यहाँ क्या हो रहा है? मैं

वाह 2017 से , आपको और क्या प्रतिक्रिया चाहिए?

आपको और क्या प्रतिक्रिया चाहिए?

यहीं??? हम सुझावों को सिर्फ इसलिए लागू नहीं करते क्योंकि वे पुराने हैं!

आपको और क्या प्रतिक्रिया चाहिए?

यहीं??? हम सुझावों को सिर्फ इसलिए लागू नहीं करते क्योंकि वे पुराने हैं!

हां। मुझे यकीन नहीं था कि यह किस तरह का था।

फिर से पढ़ना और देखना भी #40998 मुझे लगता है कि यह सबसे अच्छा तरीका है ... एमुन्स वस्तुएं हैं और मुझे लगता है कि एनम को मर्ज/विस्तारित करना आसान है।

मुझे नहीं लगता कि मैं भाषा डिजाइन पर अपनी राय देने के लिए पर्याप्त योग्य हूं, लेकिन मुझे लगता है कि मैं एक नियमित डेवलपर के रूप में प्रतिक्रिया दे सकता हूं।

मैं इस मुद्दे पर कुछ हफ़्ते पहले एक वास्तविक परियोजना में आया हूँ जहाँ मैं इस सुविधा का उपयोग करना चाहता था। मैं @alangpierce के दृष्टिकोण का उपयोग कर समाप्त हुआ। दुर्भाग्य से, मेरे नियोक्ता के प्रति मेरी जिम्मेदारियों के कारण, मैं यहां कोड साझा नहीं कर सकता, लेकिन यहां कुछ बिंदु दिए गए हैं:

1. दोहराई जाने वाली घोषणाएँ (दोनों प्रकार और एक नए एनम के लिए कास्ट) एक बड़ी समस्या नहीं थी और इससे पठनीयता को बहुत नुकसान नहीं हुआ।
2. मेरे मामले में, एनम ने एक निश्चित एल्गोरिथ्म के लिए अलग-अलग क्रियाओं का प्रतिनिधित्व किया, और इस एल्गोरिथ्म में विभिन्न स्थितियों के लिए क्रियाओं के विभिन्न सेट थे। टाइप पदानुक्रम का उपयोग करने से मुझे यह सत्यापित करने की अनुमति मिली कि कुछ क्रियाएं संकलन समय में नहीं हो सकतीं: यह पूरी बात का बिंदु था और काफी उपयोगी साबित हुआ।
3. मैंने जो कोड लिखा था वह एक आंतरिक पुस्तकालय था, और जबकि पुस्तकालय के अंदर विभिन्न एनम प्रकारों के बीच का अंतर महत्वपूर्ण था, इस पुस्तकालय के बाहरी उपयोगकर्ताओं के लिए यह कोई मायने नहीं रखता था। इस दृष्टिकोण का उपयोग करते हुए, मैं केवल एक प्रकार का निर्यात करने में सक्षम था जो कि सभी अलग-अलग एनमों का योग प्रकार था, और कार्यान्वयन विवरण को छिपाता था।
4. दुर्भाग्य से, मैं प्रकार की घोषणाओं से स्वचालित रूप से योग प्रकार के मूल्यों को पार्स करने के लिए एक मुहावरेदार और पढ़ने में आसान तरीका समझने में सक्षम नहीं था। (मेरे मामले में, मेरे द्वारा उल्लिखित विभिन्न एल्गोरिदम चरणों को रनटाइम पर SQL डेटाबेस से लोड किया गया था)। यह एक बहुत बड़ा मुद्दा नहीं था (पार्सिंग कोड को मैन्युअल रूप से लिखना काफी सरल था), लेकिन यह अच्छा होगा यदि एनम इनहेरिटेंस के कार्यान्वयन से इस मुद्दे पर कुछ ध्यान दिया जाएगा।

कुल मिलाकर, मुझे लगता है कि उबाऊ व्यावसायिक तर्क वाली बहुत सी वास्तविक परियोजनाओं को इस सुविधा से बहुत लाभ होगा। अलग-अलग उपप्रकारों में विभाजित एनम टाइप सिस्टम को बहुत सारे इनवेरिएंट की जांच करने की अनुमति देता है जो अब यूनिट परीक्षणों द्वारा जांचे जाते हैं, और गलत मानों को एक प्रकार की प्रणाली द्वारा अप्रस्तुत बनाना हमेशा एक अच्छी बात है।

नमस्ते,

मुझे अपने दो सेंट यहां जोड़ने दें

मेरा संदर्भ

मेरे पास एक एपीआई है, जिसमें ओपनएपी दस्तावेज tsoa से उत्पन्न होता है।

मेरे मॉडल में से एक की स्थिति इस तरह परिभाषित है:

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 का विस्तार होगा। मैं अधिक-जेनेरिक एनम से "पिक" करने में सक्षम होना पसंद करूंगा।

मेरा प्रस्ताब

मैंने स्प्रेड ऑपरेटर को विस्तृत प्रस्ताव से बेहतर पाया, लेकिन मैं आगे जाकर ये सुझाव देना चाहता हूं:

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

• c = a काम करना चाहिए, क्योंकि A, C का सिर्फ एक उपसमुच्चय है, इसलिए A का प्रत्येक मान C का मान्य मान है
• c = b काम करना चाहिए, क्योंकि बी सिर्फ 'a' | 'c' है जो सी के दोनों वैध मान हैं
• b = a काम कर सकता है यदि a को 'b' से अलग माना जाता है (जो केवल 'a' प्रकार के बराबर होगा)
• a = b , इसी तरह, काम कर सकता है अगर b को 'c' से अलग माना जाता है
• b = c काम कर सकता है अगर c को 'b' से अलग माना जाता है (जो कि 'a'|'c' के बराबर होगा, जो वास्तव में बी है)

या शायद हमें समानता की तुलना के लिए दाहिने हाथ की ओर एक स्पष्ट कलाकार की आवश्यकता होनी चाहिए?

एनम सदस्यों के संघर्ष के बारे में

मैं "अंतिम जीत" नियम का प्रशंसक नहीं हूं, भले ही यह स्प्रेड ऑपरेटर के साथ स्वाभाविक लगता है।
मैं कहूंगा कि, संकलक को एक त्रुटि वापस करनी चाहिए यदि या तो "कुंजी" या एनम का "मान" डुप्लिकेट किया गया है, जब तक कि कुंजी और मान दोनों समान न हों:

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'

समापन

मुझे यह प्रस्ताव टीएस देवों के लिए काम करने के लिए काफी लचीला और स्वाभाविक लगता है, जबकि वास्तव में एक एनम क्या है, इसे बदले बिना अधिक प्रकार की सुरक्षा ( as unknown as T की तुलना में) की अनुमति देता है। यह सिर्फ सदस्यों को एनम में जोड़ने का एक नया तरीका पेश करता है, और एक दूसरे से एनम की तुलना करने का एक नया तरीका है।
तुम क्या सोचते हो? क्या मुझे कुछ स्पष्ट भाषा वास्तुकला समस्या याद आई जो इस सुविधा को अस्वीकार्य बनाती है?