#394 और #103 भी देखें।

मंचों पर मैजिक स्ट्रिंग समस्या का समाधान एक सामान्य आवश्यकता है। इसके लिए जल्द ही एक आधिकारिक प्रस्ताव देखने की उम्मीद है।

हाँ, इसे एक डुप्ली के रूप में बंद करना, यह कहने के लिए पर्याप्त है कि हम निश्चित रूप से लोगों को यहां दर्द महसूस करते हैं।

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

सी # में यह दूसरी तरफ काम करता है - आपको असीमित स्ट्रिंग मिलती है। टाइपप्रति में मैं छोटा स्ट्रिंग की आवश्यकता होगी। तो शायद यह वास्तव में अलग प्रस्ताव हो सकता है :-) जैसा कि unminified भी अच्छा होगा। बस कुछ खयाल...

इस बात से सहमत। डुप्लिकेट की तरह नहीं दिखता है। एक nameof ऑपरेटर को एक बहुत अच्छा विचार माना जाना चाहिए। शायद लागू करने के लिए "आसान" भी।
मैं angularjs के साथ टाइपस्क्रिप्ट का उपयोग करता हूं और मैं अपने नियंत्रक/निर्देशक वर्गों के अंदर स्थिर स्ट्रिंग स्थिरांक बनाना पसंद करता हूं जिसका उपयोग मैं इन कक्षाओं को कोणीय मॉड्यूल में पंजीकृत करते समय करता हूं। इन नामों को हार्डकोड करने के बजाय मैं इसके बजाय nameof(MyDirectiveClass) का उपयोग करना चाहूंगा।
यह उसी तरह की समस्या है जिसे हमने पहले WPF में PropertyChanged ईवेंट (nameof/CallerMemberName से पहले) के साथ अनुभव किया था जब आपने सामान का नाम बदला था।

अच्छी बात है -- अन्य मुद्दों में इस बात को पूरी तरह से शामिल नहीं किया गया है कि यह किस बारे में बात कर रहा है

:थम्स अप:

मैं काम पर एक प्रोजेक्ट में टाइपस्क्रिप्ट का उपयोग कर रहा हूं, और रन-टाइम डक टाइप चेकर डाल रहा हूं। उपयोग का मामला URL पैरामीटर को डी-सीरियलाइज़ कर रहा है।

यदि यह सुविधा भाषा में होती, तो मैं सिंटैक्स के काम करने की अपेक्षा करता:

class Foo {
    prop: string;
}

function isFoo(obj: Foo): boolean;
function isFoo(obj: any) {
    return (typeof obj === 'object') && 
              (obj !== null) && 
              (nameof(Foo.prop) in obj);
}

// Output for isFoo()
function isFoo(obj: any) {
    return (typeof obj === 'object') && 
              (obj !== null) && 
              ('prop' in obj);
}

क्या यह सही धारणा है?

@frodegil , यह एक भयानक उपयोग का मामला होगा। मेरे दैनिक कार्य-प्रवाह से बहुत सी कोड-गंध और दोहरावदार प्रतिलिपि/चिपकाने को कम करेगा।

@ बोब्रिस , कोई उम्मीद करेगा कि मेरे उदाहरण के प्रयोजनों के लिए छोटा तार, मुझे लगता है कि अगर खनन टीएससी में अपना रास्ता बनाना था, तो यह वांछित व्यवहार होगा।

@bryanerayner , आपकी धारणा सही है। nameof ऑपरेटर का उपयोग केवल संकलन के दौरान प्रकार की जानकारी को एक स्ट्रिंग में बदलने के लिए किया जाता है।

module pd {
   export class MyAngularControllerClass {
      public static IID : string = nameof(MyAngularControllerClass);  // "MyAngularControllerClass"
      public static $inject: string[] = [Model1.IID, Model2.IID, "$scope"];
      constructor(model1: Model1, model2:Model2, $scope:angular.IScope) {
      }
      public get nameOfThisGetter() : string {
         return nameof(this.nameOfThisGetter);    // "nameOfThisGetter";
      }
   }
   angular.module(nameof(pd)).controller(MyAngularControllerClass.IID, MyAngularControllerClass);
   // angular.module("myapp").controller("OldName", MyAngularControllerClass); < out of sync
}

रिफैक्टरिंग के दौरान इन हार्डकोडेड स्ट्रिंग्स को आउट-ऑफ-सिंक प्राप्त करना इतना आसान है

यह शानदार होगा।

वाकई शानदार। ऐसे ऑपरेटर के साथ इतना कुछ किया जा सकता है।

हम देखना चाहते हैं कि #394 और #1003 के बाद चीजें 'महसूस' कैसे होती हैं। यह संभव है कि हम नए एक्सप्रेशन-लेवल सिंटैक्स को जोड़ने का सहारा लिए बिना इन उपयोग मामलों को टाइप सिस्टम में हल कर सकते हैं।

इस बीच किसी भी उपयोग के मामलों को एकत्र करना अच्छा होगा जो उन प्रस्तावों द्वारा पर्याप्त रूप से संबोधित नहीं किया जाएगा।

खैर, मामले को आंशिक रूप से @frodegil द्वारा Function/Class का एक ही नाम है), जैसा कि एंगुलर के मामले में है, है एक ऐसा मामला, जहां तक ​​मैं देख सकता हूं, #394 के memberof द्वारा या तो #394 के द्वारा नियंत्रित नहीं किया जा सकता है और न ही #103 से स्ट्रिंग शाब्दिक प्रकारों द्वारा नियंत्रित किया जा सकता है (हालांकि मैं वास्तव में बाद की प्रतीक्षा कर रहा हूं!)।

मैं सहमत हूं और समझता हूं कि कैसे एक नया सिंटेक्स तत्व जोड़ना अवांछित है और यहां तक ​​​​कि टाइपस्क्रिप्ट के मुख्य लक्ष्य (जावास्क्रिप्ट का एक पतला सुपरसेट होने के लिए) के खिलाफ जाता है, लेकिन मैं अभी भी इस प्रस्ताव को बहुत अच्छा मानता हूं।

एक और छोटा मामला

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

अभी के लिए मुझे अपने सभी मॉडलों पर क्लासनाम नामक संपत्ति को बनाए रखने की आवश्यकता है:

class Person {
  className = 'Person';

  _id: string;
  $_dateCreated: number;
}

var p:Person;
p._id = `${this.className}_${window.appMetadata.cordovaUuid}__${this.$_dateCreated}__${window.uuid.v4()}`
pouchdb.put(p)

जिसे बदला जा सकता है:

class Person {
  _id: string;
  $_dateCreated: number;
}

var p:Person;
p._id = `${nameof Person}_${window.appMetadata.cordovaUuid}__${this.$_dateCreated}__${window.uuid.v4()}`
pouchdb.put(p)

दूरदर्शी मुद्दे

मैं देख सकता हूं कि जेनेरिक या इनहेरिटेंस के साथ व्यवहार करते समय कुछ चीजों के nameof का पता लगाना थोड़ा कठिन होता जा रहा है, इसलिए मैं इस बात से सहमत हूं कि इस सुविधा पर बहुत विचार करने की आवश्यकता है।

पतले विकल्प

यह ध्यान में रखते हुए कि संपत्ति के नाम से संबंधित सभी मामलों को पूरी तरह से #394 या #1003 द्वारा नियंत्रित किया जा सकता है, मैं कहूंगा कि getClass() और getClassName() (उदाहरण यहां देखें) के एक्सपोजर से समस्या का समाधान हो जाएगा। शेष मामले जिन्हें मैं नए सिंटेक्स तत्व बनाने की आवश्यकता के बिना जानता हूं। उदाहरण के लिए यह एक कोर डेकोरेटर भी हो सकता है।

एक उपयोग का मामला जहां न तो # 394, # 2003, getClass () और न ही GetClassName () मदद करेगा, यह Angular2 में होगा:

    @Component({
        selector: 'my-selector',
        template: `<h1>{{${nameof MyComponent.prototype.title}}}</h1>`
    })
    class MyComponent { 
        public title = "Hellow world";
    }

यह कोड को रिफैक्टरिंग सबूत बनाता है, लेकिन यह इसे बहुत कम पठनीय बनाता है, इसलिए मुझे यकीन नहीं है कि यह इतना अच्छा विचार है या नहीं। सिर्फ एक विचार।

nameof लिए Enums को ध्यान में रखने के लिए यहां सुझाव जोड़ना, एक enum toString'ing के शॉर्टकट के रूप में:

nameof(MyModule.Enums.FooEnum.Bar) === "Bar"

इसके लिए संकलित होगा:

MyModule.Enums.FooEnum[MyModule.Enums.FooEnum.Bar] === "Bar"

या केवल:

"Bar" === "Bar"

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

var obj = new MyClass();
sinon.stub(obj, 'methodName', () => null); // Prone to break.

var obj = new MyClass();
sinon.stub(obj, nameof(MyClass.methodName), () => null);

या, यदि ठूंठ नाम को हल करने के लिए एक विधेय में पारित करने के लिए समर्थन करेगा:

var obj = new MyClass();
function stub<T>(targetObject: T, targetMethodPredicate: (T)=>string, methodStub: Function){}
sinon.stub(obj, x => nameof(x.methodName), () => null);

मेरे पास SQL ​​​​स्ट्रिंग्स बनाने के लिए उपयोग केस है। यहाँ एक कोड का टुकड़ा है:

interface User {
    id: string;
    name: string;
    birthday: Date;
}

// Current implementation
var sql = `SELECT id,name FROM Users`;

// Desired implementation
var sql = `SELECT ${nameof(User.id)},${nameof(User.name)} FROM ${nameof(User)}s`;

nameof() सुविधा इस प्रकार को सुरक्षित और रिफ्लेक्टर को सुरक्षित बनाएगी। उदाहरण के लिए उपयोगकर्ता तालिका का नाम बदलकर खाते में बदलना कोड के माध्यम से खोजने और इस तरह के गतिशील तारों को खोने के बजाय एक त्वरित रिफैक्टर होगा।

मैं मानता हूं कि यह एक संकलन समय परिवर्तन होना चाहिए जैसे कि यह सी # में है, इसलिए हम टाइप नाम में जला सकते हैं।

@RyanCavanaugh
पाँच महीने बाद:

1003 उतरा है लेकिन कई परिदृश्यों में मदद नहीं करता है (नीचे देखें)।

394 #1295 के पक्ष में बंद है। उत्तरार्द्ध कहीं भी लैंडिंग के पास नहीं लगता है और जब यह समस्या का एक दिलचस्प हिस्सा हल करता है (टाइपिंग) यह स्ट्रिंग/नाम भाग के साथ मदद नहीं करता है।

शायद फिर से जाने का समय?

स्ट्रिंग्स खराब हैं क्योंकि आप उन्हें "सभी संदर्भ खोजें" नहीं कर सकते हैं, आप "रिफैक्टर/नाम बदलें" नहीं कर सकते हैं और वे टाइपो के लिए प्रवण हैं।

ऑरेलिया का उपयोग करते हुए कुछ उदाहरण:

let p: Person;

// Observe a property for changes
let bindingEngine: BindingEngine;
bindingEngine.observeProperty(p, 'firstName')
             .subscribe((newValue: string) => ...);

class Person {
  firstName: string;

  // Declare a function to call when value changes
  @bindable({ changeHandler: 'nameChanged'})
  lastName: string;

  nameChanged(newValue: string, oldValue: string) { ... }

  // Declare computed property dependencies
  @computedFrom('firstName', 'lastName')
  get fullName() {
    return `${firstName} ${lastName}`;
  }
}

// Declare dependencies for validation
validation.on(p)
  .ensure('firstName').isNotEmpty()
  .ensure('fullName', config => config.computedFrom(['firstName', 'lastName'])).isNotEmpty();

वहां आपके पास पांच अलग-अलग एपीआई हैं जो nameof ऑपरेटर होने से सभी लाभान्वित होंगे।

मान्य अंक। मैं इसे फिर से लाऊंगा (ध्यान दें: हम अभी कुछ आगामी काम में बहुत व्यस्त हैं इसलिए सुझाव ट्राइएज थोड़ा बैकलॉग है)

क्षमा करें मैंने अपनी पोस्ट बहुत जल्द "Ctrl-Entered" कर दी। मैंने कई वास्तविक जीवन कोड उदाहरण जोड़े हैं जो लाभान्वित हो सकते हैं।

मामलों को और अधिक जटिल बनाने के लिए, ऊपर दिए गए कुछ एपीआई पथ भी स्वीकार करते हैं। तो @computedFrom('p.address.city') मान्य है और इसका समर्थन करना भी अच्छा होगा...

इस टिप्पणी में एक अन्य अंक में मैंने C# से किसी प्रकार के सीमित _Expressions_ का प्रस्ताव रखा।

वे इस धागे के अधिकांश उदाहरणों के लिए nameof से बेहतर विकल्प होंगे:

• वे परिणाम टाइप करने में मदद कर सकते हैं;
• वे अधिक जटिल सदस्य पहुंच (नेस्टेड, इंडेक्सर्स) का समर्थन करते हैं;
• वे आपको शुरू करने के लिए एक चर देते हैं, जो किसी मामले में आपके पास nameof दायरे में नहीं होगा।

अंतिम बिंदु का दोष यह है कि अभिव्यक्तियों में ऐसे मामले शामिल नहीं होंगे जैसे:

function f(x: number) {
  let s = nameof(x);
}

लेकिन यह अन्य उपयोग-मामलों की तरह सामान्य नहीं है।

मैं दूसरे अंक से विचार के विवरण की प्रतिलिपि बना रहा हूं:

मान लें कि हमारे पास भावों को दर्शाने के लिए एक विशेष प्रकार के तार हैं।
आइए इसे type Expr<T, U> = string ।
जहां T प्रारंभिक वस्तु प्रकार है और U परिणाम प्रकार है।

मान लें कि हम का एक उदाहरण बना सकते हैं Expr<T,U> एक लैम्ब्डा उस प्रकार के एक पैरामीटर लेता है का उपयोग करके T और प्रदर्शन उस पर एक सदस्य का उपयोग कर सकते।
उदाहरण के लिए: person => person.address.city ।
जब ऐसा होता है, तो पूरे लैम्ब्डा को एक स्ट्रिंग में संकलित किया जाता है जिसमें पैरामीटर पर जो भी एक्सेस होता है, इस मामले में: "address.city" ।

आप इसके बजाय एक सादे स्ट्रिंग का उपयोग कर सकते हैं, जिसे Expr<any, any> रूप में देखा जाएगा।

भाषा में यह विशेष Expr प्रकार होने से इस तरह की चीजें सक्षम होती हैं:

function pluck<T, U>(array: T[], prop: Expr<T, U>): U[];

let numbers = pluck([{x: 1}, {x: 2}], p => p.x);  // number[]
// compiles to:
// let numbers = pluck([..], "x");

यह मूल रूप से सी # में अभिव्यक्तियों का उपयोग करने का एक सीमित रूप है।

https://github.com/basarat/typescript-book/issues/33 में कम से कम कुछ वर्कअराउंड हैं (हालाँकि मैं अभी एक ऐसे मुद्दे में भागा हूँ जहाँ कोई अनुगामी नहीं था ';' ASP.Net के सरल खनन के कारण मेरी वापसी के बाद)

बड़ा:+1::100: समर्थन के लिए मुझसे।

मैं ऊपर दिए गए कई अन्य कारणों के लिए कामकाज का उपयोग कर रहा हूं - मुझे कुछ रिफैक्टर-फ्रेंडली चाहिए। जावास्क्रिप्ट ऑब्जेक्ट पर कुछ संपत्ति के नाम की पहचान करने के लिए स्ट्रिंग्स स्वीकार करने वाले एपीआई बहुतायत से हैं।

यहां एक वास्तविक दुनिया का उदाहरण दिया गया है जहां nameof बहुत उपयोगी हो सकता था।

मेरे पास एक वर्ग है जो एक कार्यकर्ता में दूरस्थ रूप से निष्पादित कार्यक्षमता के लिए 'नियंत्रक' के रूप में कार्य करता है। नियंत्रक वर्ग की संरचना बिल्कुल वास्तविक कार्यान्वयन वर्ग को दर्शाती है, जिसे कार्यकर्ता के भीतर निष्पादित किया जाता है।

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

export class LocalDBWorkerController<V> extends LocalDBBase<V> {
        initializeWorkerDB(options: BrowserDBOptions): Promise<void> {
            return this.executeInWorker("initializeWorkerDB", [options]);
        }

        getEntry(key: string): Promise<DBEntry<V>> {
            return this.executeInWorker("getEntry", [key]);
        }

        getEntries(keys: string[]): Promise<EntryArray<V>> {
            return this.executeInWorker("getEntries", [keys]);
        }

        getAllEntries(): Promise<EntryArray<V>> {
            return this.executeInWorker("getAllEntries");
        }

        // ...
}

यदि विधि नामों में से एक का नाम बदल दिया गया है, तो मुझे मैन्युअल रूप से इसके स्ट्रिंग प्रतिनिधित्व का नाम बदलना याद रखना होगा, अन्यथा मुझे एक रन-टाइम त्रुटि मिलेगी (यह मानते हुए कि यह कोड पूरी तरह से परीक्षण किया गया है, अन्यथा यह छूट सकता है)।

यह बहुत अच्छा होता अगर मैं सिर्फ लिख पाता:

export class LocalDBWorkerController<V> extends LocalDBBase<V> {
        initializeWorkerDB(options: BrowserDBOptions): Promise<void> {
            return this.executeInWorker(nameof(this.initializeWorkerDB), [options]);
        }

        getEntry(key: string): Promise<DBEntry<V>> {
            return this.executeInWorker(nameof(this.getEntry), [key]);
        }

        getEntries(keys: string[]): Promise<EntryArray<V>> {
            return this.executeInWorker(nameof(this.getEntries), [keys]);
        }

        getAllEntries(): Promise<EntryArray<V>> {
            return this.executeInWorker(nameof(this.getAllEntries));
        }

        // ...
}

इस मुद्दे को फिर से खोलने के लिए धन्यवाद, क्योंकि मैं वास्तव में ऑपरेटर का नाम देखना चाहता हूं।

नाम का ऑपरेटर एक संकलन समय सुविधा होगी, इसलिए रन-टाइम के प्रदर्शन पर कोई प्रभाव नहीं पड़ता है, लेकिन हम संपत्ति के नामों की रिफैक्टरिंग को सहेजते हैं और "जादू स्ट्रिंग्स" को रोकते हैं।

थोड़ी देर के लिए चर्चा की और हमें लगता है कि एक बेहतर प्रस्ताव है जो इस उपयोग के मामले को हल करता है।

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

1295 बेहतर टाइपचेकिंग भी प्रदान करता है (क्योंकि आप nameof गलत बात नहीं कर सकते हैं) जबकि कॉम्पेट समस्या से बचते हैं (आपके पास पहले से ही nameof नाम का एक फ़ंक्शन हो सकता है!) और "क्या होता है यदि ES7+ जोड़ता है यह ऑपरेटर भी" समस्या।

तुम अब भी भी कुछ अच्छी अभिव्यक्ति स्तर के सत्यापन, भी है करने में सक्षम हो क्योंकि तुम जैसे लिख सकता था <memberof MyType>"SomeMember" (जो मान्य होगा!) के बजाय nameof myTypeInstance.SomeMember । यह और भी फायदेमंद है क्योंकि अब आपको इसकी संपत्ति के नाम प्राप्त करने के लिए MyType उदाहरण की आवश्यकता नहीं है, जो कि अक्सर होता है।

<memberof MyType>"someMember"

1. शुरुआती लोगों के लिए बहुत सहज या मैत्रीपूर्ण नहीं दिखता है (अधिक सार, यह समझने की आवश्यकता है कि एक प्रकार का कास्ट क्या है, प्रकार संशोधक)।
2. लंबा। अतिरिक्त 'शोर' ( < > , " " ) जोड़ता है।
3. अनाम प्रकारों के लिए आराम से प्रयोग करने योग्य नहीं है। जैसे let x = { prop1: 123 }; let s = nameof(x.prop1) । जब तक कुछ हद तक वर्बोज़ सिंटैक्स का उपयोग नहीं किया जाता है, उदाहरण के लिए <memberof typeof x>"prop1" ।
4. घोंसले के शिकार के लिए प्राकृतिक विस्तार का सुझाव नहीं देता है। जैसे nameof(myTypeInstance.someMember.nestedMember) ।
5. संपादक स्वतः पूर्ण होने की अनुमति नहीं देता है।
6. नाम बदलने की कार्रवाई के लिए खुद को लक्ष्य प्रदान नहीं करता है (उदाहरण के लिए इसे क्लिक करना और F2 दबाना)।
7. कम जानकारीपूर्ण त्रुटि संदेश: जैसे "someMember" is not assignable to... "member1" | "member2" | .. अधिक सटीक के बजाय 'someMember' is not a member of ... ।
8. निजी या संरक्षित सदस्यों को बाहर करने का कोई तरीका प्रदान नहीं करता है (जब तक कि publicMemberof या publicOrProtectedMembersOf जैसा कुछ प्रदान नहीं किया जाता है, लेकिन यह थोड़ा अधिक वर्बोज़ लग सकता है)। मुझे लगता है कि यह बहुत महत्वपूर्ण कार्यक्षमता है - यह उस तरह की सुरक्षा है जिसकी प्रोग्रामर को आवश्यकता होती है और nameof प्रदान करने के लिए डिज़ाइन किया गया था।

मुझे लगता है कि #1295 दिलचस्प है लेकिन सबसे अधिक पूरक लगता है (वे एक साथ अच्छी तरह से काम कर सकते हैं)? यह एक अजीब निर्णय की तरह लगता है (विशेष रूप से 'अस्वीकार' फैसले-जैसे टैग के साथ जो मुझे लगता है कि यहां अनुचित है - और सामान्य रूप से)। मुझे लगता है कि nameof एक अच्छा सिंटैक्स और अवधारणा है। अत्यधिक 'तर्कसंगत' करने की आवश्यकता नहीं है या इसे लागू न करने के निर्णय को उचित ठहराने का प्रयास करने की आवश्यकता नहीं है क्योंकि यह भविष्य में एक्मास्क्रिप्ट सिंटैक्स में हस्तक्षेप कर सकता है (जो यहां प्राथमिक चिंता है, मुझे विश्वास है)।

पुन: अंक 1-4 ज्यादातर मामलों में, आप सिर्फ "someMember" लिखते हैं और सब कुछ बस काम करेगा। मैं केवल <...>" " सिंटैक्स का उपयोग करूंगा जब लक्ष्य ने memberof प्रकार प्रदान नहीं किया, जो कुछ हद तक दुर्लभ होने वाला है।

बिंदु 5 सही है।

बिंदु 6 सही नहीं है; आप उस स्थिति में नाम बदलने में सक्षम होंगे।

बिंदु 7 सही नहीं है जब लक्ष्य memberof -- मुझे लगता है कि हम वहां एक अच्छा त्रुटि संदेश प्रदान करने में सक्षम होंगे।

बिंदु 8, मैं मानता हूँ कि हमें इसका पता लगाना होगा।

विशेष रूप से 'अस्वीकार' फैसले-जैसे टैग के साथ जो मुझे लगता है कि यहां अनुचित है - और सामान्य तौर पर

मुझे यकीन नहीं है कि विकल्प क्या है?

class Example {
   a: number
   protected b: string: 
   private c: boolean;
}

function getProp(obj: Example, prop: memberof Example) {
  //..
}

nameof साथ अपेक्षित व्यवहार की तुलना में 1-4 (8 के संबंध में) के लिए यहां एक सीमा है। सीमा यह है कि nameof , कॉल के संदर्भ के आधार पर, एक अलग अपेक्षा होगी कि कौन से सदस्य वैध के रूप में शामिल होंगे। यदि कक्षा के बाहर से संदर्भित किया जाता है, तो memberof केवल "a" शामिल होने की उम्मीद की जाएगी, एक व्युत्पन्न वर्ग से यह "a" | "b" और अंदर से यह "a" | "b" | "c" । मुझे नहीं लगता कि यहां 'मॉडल' को सुंदर ढंग से करने का कोई तरीका है, क्योंकि एक प्रकार आमतौर पर प्रासंगिक रूप से निर्धारित नहीं होता है (हालांकि सबकुछ संभव है? मुझे लगता है, लेकिन मेरे पास वास्तव में परिणामों पर विचार करने का समय नहीं है)।

6 के लिए एक स्ट्रिंग के माध्यम से नाम बदलना थोड़ा अजीब लगेगा। मुझे लगता है कि यह किया जा सकता है, लेकिन चूंकि यह एक दृश्य संदर्भ में नहीं है (उदाहरण के लिए someInstance.member ) यह मानवीय गलतियों के खिलाफ भी रक्षा नहीं कर सकता है।

एज प्लेटफॉर्म स्थिति पृष्ठ शब्दावली का उपयोग करता है:

• समर्थित
• पूर्वावलोकन बिल्ड
• विकास में
• विचाराधीन
• पदावनत
• वर्तमान में नियोजित नहीं

उस पर आधारित:

• मुझे लगता है कि 'अनियोजित' (वीएस कोड गिटहब में एक मील का पत्थर के रूप में भी इस्तेमाल किया गया) 'अस्वीकृत' के लिए एक अच्छा प्रतिस्थापन (और अधिक अनुकूल) शब्द होगा: यदि समस्या बंद हो जाती है तो इसका मतलब यह होगा कि यह 'शायद कभी नहीं होगा', अगर खुला, 'शायद एक दिन, कौन जाने'।
• 'विचाराधीन' 'चर्चा में' की जगह ले सकता है (जो 'चर्चा' टैग के साथ कुछ भ्रमित करने वाला है)।
• शायद 'प्रतिबद्ध' को बदलने के लिए 'नियोजित' और 'विकास में'।
• 'डुप्लिकेट' का उपयोग कभी-कभी सुझावों के लिए किया जाता है जहां एक अलग दृष्टिकोण को प्राथमिकता दी जाती है। ये वास्तव में 'डुप्लिकेट' नहीं हैं, 'मर्ज' जैसा कुछ बेहतर काम कर सकता है (एक बेहतर शब्द हो सकता है लेकिन मैं अभी कुछ भी नहीं सोच सकता, और समय चाहिए)। _[संपादित करें: शायद 'अभिसरण' जैसा कुछ? 'मर्ज' वास्तव में गिट 'मर्ज']_ के साथ भ्रमित हो सकता है।
• इसके अलावा 'टू कॉम्प्लेक्स' -> 'नॉट वर्थवर्थ' शायद।

मुझे लगता है कि इनमें से कुछ विकल्प इस तथ्य को भी बेहतर ढंग से दर्शाते हैं कि यह वास्तव में एक 'समुदाय' निर्देशित परियोजना नहीं है (जैसे Node.js)। 'चर्चा में' जैसे शब्द ऐसा लग सकता है कि यह डिज़ाइन टीम के बजाय 'समुदाय' पर चर्चा में हो सकता है (कम से कम मैंने पहले ऐसा ही सोचा था)। 'अस्वीकार' थोड़ा चरम लगता है (कभी नहीं कहना कभी नहीं ..)। मेरे लिए ऐसा लगता है कि यह फीचर अनुरोधों को थोड़ा सा विशेषता देता है जैसे वे 'मांग' या यहां तक ​​​​कि 'परीक्षण' भी थे। कभी-कभी वे सिर्फ 'विचार', विचार, या जरूरतों की प्राथमिक अभिव्यक्ति, जांच के लिए बिंदु आदि होते हैं। कभी-कभी वे केवल 'चरणों' या बेहतर लोगों के लिए सूचना के स्रोत के रूप में काम कर सकते हैं।

मैं इन पर काम करने के लिए कुछ व्यक्तिगत प्रयास करने को तैयार हूं। हो सकता है कि मैं एक मेटा-मुद्दा खोलूं जब मेरे पास शब्दों का एक और पूरा सेट होगा जो मुझे लगता है कि यह काफी अच्छा है।

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

@RyanCavanaugh

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

मेरे द्वारा ऊपर दिए गए दिया गया है । मेरा वर्तमान समाधान ES6 name संपत्ति को फ़ंक्शन इंस्टेंस के लिए पॉलीफ़िल करना है , यदि आवश्यक हो, लक्ष्य ऑब्जेक्ट में सभी विधियों के लिए और इसके सभी प्रोटोटाइप में:

(V8 के संस्करण 5.0 को ES6 को लक्षित करते समय इस पॉलीफ़िल की आवश्यकता नहीं है, मेरा मानना ​​​​है कि (क्रोम में 50 .name वर्ग विधियों के लिए काम करता है) हालांकि नोड 6.0 में कुछ कार्यक्षमता अभी भी एक ध्वज के पीछे है ):

function polyfillMethodNameProperties(obj: any) {
    while (obj != null && obj !== Function.prototype && obj !== Object.prototype) {
        for (let propName of Object.getOwnPropertyNames(obj)) {
            let member = obj[propName];

            // Note: the latest Edge preview would resolve the name to 'prototype.[name]' 
            // so it might be better to force the polyfill in any case even if the 
            // feature is supported by removing '&& !member.name'
            if (typeof member === "function" && !member.name)
                Object.defineProperty(member, "name", {
                    enumerable: false,
                    configurable: true,
                    writable: false,
                    value: propName
                });
        }

        obj = Object.getPrototypeOf(obj);
    }
}

class LocalDBWorkerController<V> extends LocalDBBase<V> {
        constructor() {
            polyfillMethodNameProperties(this);
        }

        initializeWorkerDB(options: BrowserDBOptions): Promise<void> {
            return this.executeInWorker(this.initializeWorkerDB.name, [options]);
        }

        getEntry(key: string): Promise<DBEntry<V>> {
            return this.executeInWorker(this.getEntry.name, [key]);
        }

        getEntries(keys: string[]): Promise<EntryArray<V>> {
            return this.executeInWorker(this.getEntries.name, [keys]);
        }

        getAllEntries(): Promise<EntryArray<V>> {
            return this.executeInWorker(this.getAllEntries.name);
        }

        // ...
}

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

object प्रकार वाले सदस्यों का समर्थन करने के लिए एक अलग, लेकिन अधिक सामान्य दृष्टिकोण लागू किया जा सकता है (लेकिन string , number , boolean जैसे आदिम प्रकार वाले सदस्य नहीं हैं। null या undefined क्योंकि उनकी तुलना संदर्भ द्वारा नहीं की जा सकती है), और सदस्यों के पुन: असाइनमेंट के लिए भी अनुमति देता है। मैंने यहां जिस दृष्टिकोण का उपयोग किया है, वह ES6 Map ऑब्जेक्ट पर निर्भर करता है, यदि उपलब्ध हो, तो गुणों की सूची को कैश करने के लिए:

let propertyNameCache: Map<any, string[]>;

function getAllPropertyNames(obj: any): string[] {

    let scanAllPropertyNames = (): string[] => {
        let propertyNames: string[] = [];

        while (obj != null) {
            Array.prototype.push.apply(propertyNames, Object.getOwnPropertyNames(obj));
            obj = Object.getPrototypeOf(obj);
        }

        return propertyNames;
    }

    if (typeof Map === "function") {
        if (propertyNameCache === undefined)
            propertyNameCache = new Map<any, string[]>();

        let names = propertyNameCache.get(obj);

        if (names === undefined) {
            names = scanAllPropertyNames();
            propertyNameCache.set(obj, names);
        }

        return names;
    }
    else {
        return scanAllPropertyNames();
    }
}

function memberNameof(container: any, member: any): string {
    if (container == null || (typeof container !== "function" && typeof container !== "object"))
        throw new TypeError("memberNameof only works with non-null object or function containers");

    if (member == null || (typeof member !== "function" && typeof member !== "object"))
        throw new TypeError("memberNameof only works with non-null object or function values");

    for (let propName of getAllPropertyNames(container))
        if (container[propName] === member)
            return propName;

    throw new Error("A member with the given value was not found in the container object or any of its prototypes");
}

उपयोग उदाहरण:

class Base {
    dcba = {};
}

class Example extends Base {
    abcd = {};
}

let example = new Example();
console.log(memberNameof(example, example.abcd)); // prints "abcd"
console.log(memberNameof(example, example.dcba)); // prints "dcba"

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

@RyanCavanaugh वैकल्पिक लेबल सुझावों पर काम 95% किया गया है, मैंने लगभग सभी मौजूदा लेबलों को कवर किया है (इसमें कई घंटे लगे हैं) - सबसे कठिन लेबल Declined लेबल ही निकला :) इसलिए इसमें कुछ अतिरिक्त सप्ताह या महीने भी लग सकते हैं।

<memberof MyType>"SomeMember"

यह और भी अधिक फायदेमंद है क्योंकि अब आपको इसके गुण नाम प्राप्त करने के लिए MyType के उदाहरण की आवश्यकता नहीं है

सी # में आप लिख सकते हैं var संपत्तिनाम = nameof(MyType.SomeMember)

ऐसा लगता है कि दोनों नाम और सदस्य समझ में आता है। सदस्य प्रकार एनोटेशन के लिए उपयोगी है, ऑब्जेक्ट के सदस्यों के नाम, चर, फ़ंक्शन पैरामीटर, कक्षाएं, इंटरफेस, नेमस्पेस इत्यादि के नाम प्राप्त करने के लिए नाम ...

तो मुझे समझ नहीं आया - क्या कोई नाम का ऑपरेटर होगा या नहीं? क्योंकि टिकट बंद है लेकिन कमेंट आते रहते हैं :)

जब मैंने इसकी खोज की तो मैं यहां पहुंचा: TypeScript CallerMemberName

सी # की [कॉलरमेम्बरनाम] विशेषता जैसे कुछ ढूंढ रहे हैं। नामोफ़ के समान नहीं है, लेकिन कुछ मामलों में एक विधि लिखने के लिए उपयोग किया जाता है ताकि कॉलर को नाम का उपयोग भी न करना पड़े; उदाहरण के लिए, यह सूचित करना कि कुछ संपत्ति बदल गई है, आदि।

क्या इसके लिए कोई अलग मुद्दा है, या इसे ऐसा ही माना जाता है?

@DaveEmmerson यह एक अलग विषय है। CallerMemberName जावास्क्रिप्ट में रन-टाइम पर पाया जा सकता है।

यह समस्या एक चर नाम के _compile-time_ बर्न-इन के लिए है, जो रन-टाइम पर उपलब्ध नहीं है।

@styfle अगर आप उस धागे को पढ़ते हैं तो यह वास्तव में लगातार रनटाइम पर नहीं किया जा सकता है।

मैं C# में CallerMemberName जैसे संकलन समय और नाम की तरह बात कर रहा हूं। मैं उन्हें एक समान तंत्र के रूप में देखता हूं, लेकिन मुझे लगता है कि अगर यह मुद्दा अपने अंत तक पहुंच गया है तो इसका एक समान निष्कर्ष होगा।

बस एक ख्याल था... :)

मुझे यह अनिच्छा भी नहीं आती

nameof केवल एक मैक्रोज़ है जो एक संपत्ति नाम पहचानकर्ता को सिंटैक्स स्तर पर एक स्ट्रिंग अक्षर में बदल देता है, इसे जोड़ने के लिए इतना बड़ा सौदा क्यों है?

मैंने इस समस्या को एक बेबेल प्लगइन के साथ हल किया: https://github.com/enoshixi/babel-plugin-nameof

मैं इसे कुछ महीनों के लिए उत्पादन साइटों में उपयोग कर रहा हूं और यह एक आकर्षण की तरह काम करता है। अंत में इसे जीथब पर लाने में कामयाब रहे।

क्या उस बेबेल प्लगइन को TS एप्लिकेशन में स्थापित किया जा सकता है और एक साथ काम कर सकता है?

मेरा उपयोग-मामला एक फॉर्म लाइब्रेरी है जिसे मैंने विकसित किया है। मैं निम्नलिखित जैसे रिफैक्टरिंग-संगत और संकलन-समय-जांच सिंटैक्स का उपयोग करने में सक्षम होना चाहता हूं:

// Press F2 to rename properties:
let myObj = { firstName: "John", enableTLAFeature: true, uglyPropName: "" }; 
let myForm = new Form( [ 
  new TextBox  ( myObj, nameof( myObj.firstName ), { required: true, maxLength: 20 } ), 
  new Checkbox ( myObj, nameof( myObj.enableTLAFeature ) ),
  new TextBox  ( myObj, nameof( myObj.uglyPropName ), { label: "Better Label" } )
] );

घटक निर्माता वस्तु, संपत्ति का नाम (एक स्ट्रिंग के रूप में), और एक वैकल्पिक विकल्प वस्तु लेते हैं।

वे फॉर्म घटक संपत्ति को पढ़ने और लिखने में सक्षम होंगे (obj [propName] वाक्यविन्यास का उपयोग करके) और विकल्प ऑब्जेक्ट में कोई भी प्रदान नहीं किए जाने पर स्वचालित रूप से डिस्प्ले लेबल उत्पन्न करते हैं (प्रत्येक घटक में लेबल का प्रतिपादन शामिल होता है)। मैं संपत्ति के नाम को एक सहायक फ़ंक्शन के साथ एक फॉर्म लेबल में परिवर्तित कर सकता हूं। फ़ंक्शन पहले अक्षर को अपर केस में कनवर्ट करता है और प्रत्येक लोअर केस लेटर के बाद एक स्पेस डालता है जब अपर केस लेटर के बाद और किसी भी अपर केस लेटर से पहले लोअर केस लेटर के बाद होता है। उदाहरण के लिए, "फर्स्टनाम" "फर्स्ट नेम" बन जाता है और "enableTLAFeature" "सक्षम टीएलए फीचर" बन जाता है। (यदि हमें एक बेहतर लेबल की आवश्यकता है, तो इसे विकल्प ऑब्जेक्ट में स्पष्ट रूप से प्रदान किया जा सकता है।)

नोट: नेस्टेड ऑब्जेक्ट्स के लिए, मैं नेस्टेड ऑब्जेक्ट को पहले पैरामीटर में पास करता हूं, जैसे myObj.address और मुझे उम्मीद है कि nameof(myObj.address.city) को कंपाइल-टाइम पर "city" में कनवर्ट किया जाएगा (I मैं घटकों के भीतर संपत्ति पथ नेविगेशन नहीं कर रहा हूं, इसलिए मुझे जटिल अभिव्यक्ति समर्थन की आवश्यकता नहीं है)। इस दृष्टिकोण के साथ, myObj, पता और शहर का नाम सुरक्षित रूप से बदला जा सकता है।

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

ऐसा कुछ बहुत उपयोगी हो सकता है।

nameof<Foo> प्रकट होना चाहिए (सभी उद्देश्यों और उद्देश्यों के लिए) "Foo" इस तरह संकलक/एमिटर बस इसे एक स्ट्रिंग के रूप में सोच सकता है।

लेकिन nameof<T> जो ट्रैक करता है कि वास्तव में T क्या है, DI कंटेनरों के लिए बहुत उपयोगी हो सकता है। उदाहरण के लिए:

registerConstant<T>(instance:T){
   this.container[nameof<T>] = instance;
}

तो आप आईओसी के लिए इंटरफ़ेस समस्या को हल कर सकते हैं:

बंधन:
ioc.registerConstant<IFoo>(new Foo());

इंजेक्शन लगाना:

constructor(@inject(nameof<IFoo> foo:IFoo){... }

मैंने ऐसा करने के लिए एक छोटा प्रयोगात्मक पुस्तकालय बनाया: https://github.com/dsherret/ts-nameof

यह अभी भी एक कार्य प्रगति पर है। मुझे पता है यदि आप किसी को भी सुझाव देते है।

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

@MeirionHughes : यह जावास्क्रिप्ट में कैसे अनुवाद करेगा?
मुझे नहीं लगता कि यह इस बहुत ही सरल विकल्प से बहुत बेहतर है:
ioc.registerConstant(nameof(IFoo), new Foo());

किसी संपत्ति या फ़ंक्शन का नाम प्राप्त करना (चर्चा का मूल विषय) एक प्रकार का नाम प्राप्त करने जैसा नहीं है, इस पर विचार करें:

• nameof<[]> - इसका नाम क्या है?
• nameof<{ coolStuff: MyType & MyOtherType & MyFavoritType | undefined | null | SomethingCompleteltyDifferent<Dictionary<string, Promise<Optional<PleaseStop>>[]>>; }>
• nameof<string | number> बनाम nameof<number | string>

साथ चलने दो

• nameof<string> बनाम nameof<"string">

यह भी दिलचस्प है:

• type N = number; nameof<number | N | number>

रुको रुको, यहाँ और है:

function helloEarthings<a, b, c extends a<b>>(one: number, two? = new class { hi = 'how are you?'  }, ...blah: MyMegaControl<typeof someOtherValueIJustMadeUp>[]) {
}
nameof<typeof helloEarhlings>

• गुणों के नाम का क्रम:

nameof<{
    shouldWeGoLexical: 'hm'
    orAlphabetical: 'hm'
}>

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

@MeirionHughes आप समझते हैं कि एक प्रकार जैसा लिखा गया है (एएसटी में) वैसा नहीं है जैसा इसे पढ़ा गया था, आंतरिक रूप से संग्रहीत किया गया था और टाइपस्क्रिप्ट द्वारा व्याख्या की गई थी, है ना?

उदाहरण:

const myVariable = 'hey';
type A = typeof myVariable
type B = 'hey';

nameof<A> === nameof<B> // <-- ???
nameof<typeof myVariable> === nameof<A> // <-- ???
nameof<'hey'> === nameOf<A> === nameof<typeof myVariable> // <-- ???

@ एलेक्सी-बायकोव: नामोफ़ को परिभाषा के अनुसार अनाम अभिव्यक्ति के साथ काम नहीं करना चाहिए। आप किसी ऐसी चीज का नाम नहीं ले सकते जिसका कोई नाम नहीं है।

• nameof(Array) -> "सरणी"
• nameof([]) -> संकलक त्रुटि
• let arr = []; nameof(arr) -> "गिरफ्तारी"
• nameof(string) -> "स्ट्रिंग"
• nameof(String) -> "स्ट्रिंग"
• nameof("string") -> संकलक त्रुटि
• type N = number; nameof(N) -> "एन"
• nameof(number | N | number) -> संकलक त्रुटि
• nameof({ coolStuff: MyType }) -> संकलक त्रुटि

हालांकि, यह काम करना चाहिए:

• nameof(Array.length) -> "लंबाई"
• let arr = []; nameof(arr.length) -> "लंबाई"
• interface IPerson { firstName: string }; nameof(IPerson.firstName) -> "फर्स्टनाम";
• let arr: Array<IPerson> nameof(arr[0].firstName) -> "फर्स्टनाम"

यह सब पहले से ही सी # में परिभाषित किया गया है और वास्तविक जीवन में परीक्षण किया गया है और यह अच्छी तरह से काम करता है।

मैं JSX सम्मान में संघर्ष से बचने के लिए nameof() नोटेशन को nameof<> से अधिक पसंद करता हूं। टीएसएक्स। यह शायद सबसे आम परिदृश्य होगा:

<input name={nameof(this.state.firstName)} />

@Liero , सी # के साथ समानता का पालन करना मुश्किल है क्योंकि, वे 2 अलग-अलग भाषाएं हैं: सी # में यूनियन और चौराहे के प्रकार के साथ-साथ गैर-स्थानीय अज्ञात प्रकार नहीं हैं, टीएस के लिए यह सब रोटी और मक्खन है

यह मेरे लिए स्पष्ट नहीं है कि अंतिम नाम प्राप्त करने में सक्षम होने के लिए योग्यता क्या है जिस पर एक प्रकार पंजीकृत किया गया था, टीएस में केवल 40% मामले हैं जहां इस तरह के प्रश्न विभिन्न अज्ञात प्रकार के भावों के कारण भी समझ में आते हैं

के अतिरिक्त:

• interface A { x: number; }
• interface B extends A {}
• type C = B;
• type D = A;
• type E = C | D

टीएस में सभी 100% एक ही प्रकार के हैं (संरचनात्मक टाइपिंग के लिए धन्यवाद), मुझे उन्हें अलग-अलग नामों (आपके अनुसार) के तहत देखने से कैसे फायदा होगा?

@ अलेक्सी-बायकोव
nameof() प्रकार पर उपयोग करने के लिए नहीं है, लेकिन पॉइंटर्स पर अधिकतर यदि न केवल। हमें उस सूचक के प्रकार की परवाह नहीं है, मुझे बस इसका नाम चाहिए।

const a: { what: string;}
const b: { what: number;}
const c: { what: any;}
const d: { what: undefined;}
const e: { what: never;}
const f: { what: {};}
const g: { what: typeof a;}
const h: { what: typeof b | typeof c;}
const i: { what: Whatever | You | Need | Ever;}

nameof(a.what) == 'what';
nameof(b.what) == 'what';
nameof(c.what) == 'what';
nameof(d.what) == 'what';
nameof(e.what) == 'what';
nameof(f.what) == 'what';
nameof(g.what) == 'what';
nameof(h.what) == 'what';
nameof(i.what) == 'what';

// they're all the same, regardless of the type

अब, यदि आप nameof() एक प्रकार पूछने के बारे में बात कर रहे हैं, तो मैं @Liero से सहमत

मुझे व्यक्तिगत रूप से ऐसा लगता है कि nameof का वास्तविक मूल्य रन टाइम पर प्रकार की जानकारी प्राप्त करने में नहीं है, बल्कि स्ट्रिंग अक्षर का उपयोग करते समय प्रकार की सुरक्षा प्रदान करना है। जैसा कि ऊपर उल्लेख किया गया है, मैं वर्तमान में एक बेबेल प्लगइन का उपयोग कर रहा हूं जो nameof को लागू कर रहा है; यहाँ मेरे लिए एक बहुत ही विशिष्ट उपयोग का मामला है (React का उपयोग करना क्योंकि मैं वर्तमान में इसके साथ काम कर रहा हूँ इसलिए यह मेरे दिमाग में ताज़ा है, लेकिन अवधारणा कहीं और लागू की जा सकती है):

interface FooBar {
  foo: string;
  bar: string;
}

interface Props {
  value: FooBar;
  onChange(value: FooBar) => void;
}

const FooBarControl = (props: Props) => {
  const handleChange = (event: React.FormEvent, name: string) => {
    const { value } = event.currentTarget as HTMLInputElement;
    const newValue = Object.assign({}, props.value, { [name]: value });
    props.onChange(newValue);
  };

  return (
    <div>
      <input value={props.foo} onChange={e => handleChange(e, nameof(props.foo))}/>
      <input value={props.bar} onChange={e => handleChange(e, nameof(props.bar))}/>
    </div>
  );
};

रनटाइम के दौरान एक शाब्दिक स्ट्रिंग के रूप में संपत्ति के नाम का उपयोग करके उन्हें अपडेट करने के बावजूद, मैं फू या बार गुणों का स्वतंत्र रूप से नाम बदल सकता हूं और कुछ भी नहीं टूटता है।

@ एलेक्सी-बायकोव: नामोफ़ ऑपरेटर से प्रकार की जानकारी प्राप्त करने की अपेक्षा न करें। यह एक भयानक गलती होगी। हो सकता है कि type N = number; nameof(N) में वास्तविक उपयोग के मामले न हों, लेकिन स्पष्टता और स्थिरता के लिए, यह एकदम सही समझ में आता है। if(true){} भी वास्तविक उपयोग का मामला नहीं है, लेकिन आप इसे लिख सकते हैं।

@fredgalvao आप गुणों के नामों के बारे में बात कर रहे रखती है और मैं उस पर आपके साथ हूं

@Liero यदि आपको प्रकार की जानकारी की परवाह नहीं है, तो शायद हमें इसे उन गुणों के नामों तक सीमित कर देना चाहिए जो प्रकार नहीं हैं, बल्कि मूल्य घोषणाएं हैं क्योंकि उनका नाम उन मूल्यों से संबंधित है जो उत्सर्जित जेएस में विरोध के रूप में रहने के लिए हैं उन प्रकारों के लिए जो पूरी तरह से मिट जाते हैं

2 अलग-अलग डोमेन हैं जिनसे TS डील करता है:

• वैल्यू डोमेन - सब कुछ जो उत्सर्जित जेएस के साथ करना है क्योंकि जेएस में हर छोटी चीज एक वस्तु है
• डोमेन टाइप करें - अल्पकालिक चीजें जो कोड की स्थिरता के बारे में तर्क देने में मदद करती हैं जो उत्सर्जित जेएस का हिस्सा नहीं हैं

अभी

• मूल्यों के नाम प्राप्त करना सही समझ में आता है क्योंकि उनका मतलब जेएस में चीजें हैं
• प्रकारों के नाम प्राप्त करने का कोई मतलब नहीं है, क्योंकि परिणामी JS में ऐसा कुछ भी नहीं है जिसका उनसे कोई लेना-देना हो

को छोड़कर... कक्षाएं!

कक्षाएं गोधूलि क्षेत्र में हैं क्योंकि उनके पास मूल्यों और प्रकारों दोनों के गुण हैं: वे प्रोटोटाइप ऑब्जेक्ट और कंस्ट्रक्टर फ़ंक्शन के कारण मूल्य हैं, वे प्रकार हैं क्योंकि वे इसके उदाहरणों के लिए वैध संचालन के एक सेट को नियंत्रित करते हैं।

गुणों, कार्यों, चर जैसे सभी तुच्छ मूल्यों के साथ कक्षाएं nameof ऑपरेटर के अधीन होनी चाहिए

@ एलेक्सी-बायकोव: यह चर्चा का विषय है, लेकिन मुझे कक्षा के नाम के साथ नाम के लिए उपयोग का मामला दिखाई देता है:

describe(nameof(Person)) {
   it(nameof(Person.sayHello) + `() should say "Hello!"`, function() {
      expect(new Person().sayHello()).toBe("Hello!");
   });
}

यह आसान रिफैक्टरिंग के लिए अनुमति देता है। हालांकि जोड़ा गया मूल्य अपेक्षाकृत छोटा है, मुझे इसे सीमित करने का कारण नहीं दिख रहा है।

एफवाईआई, इस प्रकार सी # काम करता है:

class A {}
nameof(A)
"A"
using B = A;
nameof(B)
"B"

कोई बात नहीं क्या कभी।

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

@Liero इस बारे में कोई सवाल नहीं है कि कक्षाओं को nameof लिए एक विषय बनाया जाए, क्योंकि कक्षाएं मूल्य हैं, इसलिए उन्हें वहां रहने देना स्वाभाविक है, मुझे कोई समस्या नहीं दिखती है

@ YipYipX4 मैंने आपको सुना है, संपत्तियों का जन्म nameof , इसलिए चिंता न करें, वे नाम योग्य होंगे

प्रकारों के नाम प्राप्त करने का कोई मतलब नहीं है, क्योंकि परिणामी JS में ऐसा कुछ भी नहीं है जिसका उनसे कोई लेना-देना हो

जो पूरी तरह से बिंदु है; इंटरफेस में रन-टाइम उपस्थिति बिल्कुल नहीं है ... जो एक समस्या है, खासकर यदि आप प्रतिबिंब के आधार पर नियंत्रण में उलटा करना चाहते हैं।

एक नज़र डालें कि कैसे इनवर्सिफाई समस्या का समाधान कर रहा है

मूल रूप से यदि आपके पास interface IFoo है तो आपको कहीं भी "IFoo" स्ट्रिंग को परिभाषित करना होगा ताकि जब आप जावास्क्रिप्ट प्राप्त करें तो आपके पास वास्तविक मूल्य हो। इंटरफ़ेस नाम रखने में सक्षम होने के नाते (nameof जैसी किसी चीज़ के माध्यम से उत्सर्जित होना यह सुनिश्चित करने में उपयोगी होगा कि अपवर्तन उन प्रतीकों को नहीं तोड़ता है।

तो उलटा उदाहरण दिया गया है, आप यह कर सकते हैं:

public constructor(
  @inject(nameof(Katana)) katana: Katana,
  @inject(nameof(Shuriken)) shuriken: Shuriken
)

@MeirionHughes इंटरफेस में रनटाइम उपस्थिति नहीं होनी चाहिए, इंटरफेस केवल प्रकार हैं जिन्हें नाम दिए गए थे, प्रकार सभी भ्रामक संस्थाएं हैं जिनका एकमात्र उद्देश्य टाइपचेकिंग में सहायता करना है

अब, आप जो चाहते हैं, वह यह है कि आप उन्हें अतिरिक्त जिम्मेदारियां देकर उन्हें पुनर्व्यवस्थित करें, अर्थात् बंधन जो एक साथ रहें

• एक निश्चित वस्तु के लिए एक रनटाइम अपेक्षा और
• कोड का एक टुकड़ा जो अपेक्षित वस्तु प्रदान करके इस अपेक्षा को पूरा करता है

टीएस में इंटरफेस को ऐसा नहीं करना चाहिए था जैसा कि डिज़ाइन किया गया है, यह वह नहीं है जो वे करते हैं, उनके पास रनटाइम में 0 व्यवसाय है

शायद जो आपको भ्रमित करता है वह है नाम inteface और आपकी सी # पृष्ठभूमि जहां से आपके पास रनटाइम व्यवहार के कुछ निश्चित निष्कर्ष हैं, फिर से सी # और टीएस बहुत अलग हैं हालांकि कुछ वाक्यविन्यास और कीवर्ड साझा करते हैं

अपने इंजेक्शन ढांचे पर वापस यह ठीक वैसे ही काम करेगा यदि कार्यान्वयन को उन स्थानों के साथ जोड़ने के लिए सादे तारों का उपयोग कर रहा था जो उस पर निर्भर हैं:

@injectable('one-thing')
class A {}
@injectable('another-thing')
class B {}
class C {
   constructor(
     @inject('one-thing') katana: Katana,
     @inject('another-thing') shuriken: Shuriken
   ) {}
}

@ एलेक्सी-बायकोव यहां इंटरफेस के लिए उपयोग का मामला है ।

निश्चित रूप से कोई यह सब स्थिरांक में रख सकता है, लेकिन अगर कोई अपने निरंतर स्ट्रिंग मानों को लाइन में रखने के लिए इंटरफेस के साथ नाम का उपयोग करना चाहता है, तो मुझे ऐसा करने की अनुमति न देने का एक अच्छा कारण नहीं दिखता है।

@dsherret

मैंने इसे पहले ही देख लिया है, धन्यवाद, TS इंटरफ़ेस के नाम का उपयोग करने से कोई समस्या हल नहीं होगी , इस पर विचार करें:

@injectable() 
class Broom extends Broom { sweep(): void {} }

@injectable()
class Katana extends Katana { cut(): void {} }

class Ninja{
    constructor(
        @inject(nameof(Broom)) katana: Katana // <-- did i get my sword yet?
    ) { }
}

प्रशन:

• इस तरह की बुरी चीजों को होने से रोकने के लिए nameof क्या कर सकता है?
• अगर यह नहीं कर सकते हैं, यह कैसे सादे तार का उपयोग कर से बेहतर है "broom" के बजाय की तरह nameof(Broom)?

@ एलेक्सी-बायकोव यह आपको "झाड़ू" के बजाय "झाड़ू" करने से रोकेगा;)

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

@dsherret इससे पहले कि मैं कहूं कि यह परेशानी के लायक नहीं है, आइए इसे थोड़ा और आगे ले जाएं, इसलिए nameof एक नई सुविधा है जो एक इंटरफ़ेस ले सकती है, मेरे ORM ढांचे में मेरे पास एक इंटरफ़ेस है interface IColumn<TValue> { } , अब मुझे nameof(Column<number>) करने की ज़रूरत है यह मुझे क्या देगा? (संकेत, आज मेरी पहली टिप्पणी देखें)

@ एलेक्सी-बायकोव मैं कहूंगा कि प्रकार के तर्कों को बाहर रखा जाना चाहिए- nameof(Column<number>) "Column" जाना चाहिए। अगर कोई टाइप arg चाहता था तो वे कर सकते थे: nameof(number); । मैंने यहां यही किया। यदि ऐसा नहीं किया जाता है, तो टाइप args वाले इंटरफ़ेस का नाम आसानी से प्राप्त करने का कोई तरीका नहीं है ...

सी#:

     nameof(A.B.C.D);  => "D"  // namespace A.B.C.D 
     nameof(A.B.C.D.IX); => "IX"  // interface IX in namespace A.B.C.D
     nameof(variableName); => "variableName";
     nameof(A.B.C.D.IX<int>); => "IX"  // interface IX<T> in namespace A.B.C.D;
     nameof(instance.Name); => "Name" // property Name of object instance

टाइपप्रति:

     nameof(A.B.C.D); => "D"  // module A.B.C.D
     nameof(A.B.C.D.IX); => "IX" // interface IX in module A.B.C.D
     nameof(variableName) => "variableName";
     nameof(A.B.C.D.IX<number>); => "IX" // interface IX<T> of module A.B.C.D
     nameof(instance.Name); => "Name" // property name of object instance

नाम के तार की गणना संकलन-समय पर की जा सकती है और टाइपस्क्रिप्ट में भी संभव होना चाहिए।
यह बहुत सारे परिदृश्यों को हल करता है जहां विभिन्न जावास्क्रिप्ट ढांचे में स्ट्रिंग-नाम और टाइप-नाम (1 से 1) का उपयोग किया जाता है। यह री-फैक्टरिंग को इतना आसान बना देगा (मॉड्यूल नाम, नियंत्रक नाम, कोणीयज में निर्भरता इंजेक्शन, वगैरह)
नामोफ़ काम को उसी तरह क्यों न करें जैसे सी # में?

@ एलेक्सी-बायकोव मैं आपसे सहमत हूं कि प्रकारों के लिए nameof() वास्तव में गड़बड़ हो जाता है, लेकिन मुझे नहीं लगता कि हमें एक संतोषजनक समाधान/कार्यान्वयन प्रदान करने के लिए वहां जाने की आवश्यकता है जिसमें 99% परिदृश्य शामिल हैं।

सामान्य चीज़ें

• हम पहले से ही जानते हैं और सहमत हैं कि गुण/फ़ील्ड/चर 100% (या होने की उम्मीद) शामिल हैं।
• हम कक्षाओं पर nameof() को सीमित कर सकते हैं ताकि यह सबसे तत्काल डाउन-द-ट्री परिभाषित नो-टाइप-पैरामीटर नाम ( Class<TypeParam<What<Is<Going | On>>>> -> "Class" ) प्राप्त कर सके। मेरा मतलब है, अगर आप इसे पहचानने योग्य बनाना चाहते हैं, तो बस इसे उपनाम दें:

type ClassFromHell = Class<TypeParam<What<Is<Going | On<I | DONT | EVEN>>>>>;

अभूतपूर्व बात

• हम nameof() को कंपाइल-टाइप-ओनली टाइप एक्सप्रेशन (इंटरफेस, एब्स्ट्रैक्ट क्लासेस, इनलाइन डेफिनिशन, टाइप एलियास, मॉड्यूल डेफिनिशन, आदि) पर सीमित कर सकते हैं ताकि ऊपर की कक्षाओं के लिए मैंने जो सुझाव दिया, उसके समान सरल और सीमित तरीके से व्यवहार किया जा सके। : बस स्ट्रिंग इनलाइन को आउटपुट करें जहां इसे कहा जाता है।

क्या यह पहली चीज होगी जो इसे टीएस से रनटाइम तक संकलित शून्य के माध्यम से बनाती है? शायद। लेकिन क्या यह बुरा है? मैं ऐसा जरूरी नहीं सोचता।

मैं वास्तव में nameof() को अवधारणा की प्रत्येक आवश्यकता को हल करने में सक्षम नहीं देख सकता, इसलिए मैं इसे पूरी तरह से चित्रित करने के लिए भी नहीं कहूंगा। लेकिन अन्य 99% मामलों को उस 1% समस्याग्रस्त होने के कारण पकड़ना एक अच्छा विचार नहीं लगता है। हम उस चीज़ के साथ काम नहीं कर रहे हैं जिसके बारे में एक्मास्क्रिप्ट सोचता है, इसलिए हमें किसी मसौदे या विनिर्देश का सख्ती से पालन करने की आवश्यकता नहीं है, और इस तरह हम इस _faulty_ संस्करण को स्वीकार कर सकते हैं, जो मेरे लिए पहले से ही 10^10*awesome है।

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

अब जब विचार सरल और स्पष्ट है और इसका तत्काल लाभ सभी के लिए स्पष्ट है, यह एक कहानी है

तो कोई नहीं कहेगा? ठीक है, अगर हम एक विशेष interface मामले के बारे में बात कर रहे हैं, जो केवल प्रकार के मापदंडों के बिना काम करता है, और हम वास्तव में नहीं जानते कि अन्य सभी प्रकारों के साथ क्या करना है, क्योंकि अवधारणा का कोई मतलब नहीं है, अकेले रहने दें सहज ज्ञान युक्त, ऐसा लगता है कि पहले से ही एक समस्या है ...

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

अब तक कोई अच्छा उदाहरण नहीं था कि हमें इंटरफेस के लिए nameof आवश्यकता क्यों है, इसके अलावा कोड लिखने और बनाए रखने के लिए इतना आसान होने के बारे में असमर्थित बयानों के अलावा

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

मुझे नहीं पता कि अब तक यहां पोस्ट किए गए उदाहरणों को "असमर्थित बयान" कैसे माना जाता है। उनमें से अधिकांश वास्तविक दुनिया के परिदृश्य हैं, विशेष रूप से IoC, कई अलग-अलग पुस्तकालयों और रूपरेखाओं को शामिल करने वाली कई परियोजनाओं में उपयोग किया जाता है। बेहतर कोड लिखने और इसे आसानी से बनाए रखने में सक्षम होने के कारण टाइपस्क्रिप्ट को शुरू करने के लिए बनाया गया था। उदाहरण के लिए, हमारे पास एचकेटी नहीं है, लेकिन हमारे पास अभी भी टीएस v2.0 तक पहुंच रहा है: विंक:। मैं फिर से * सहमत हूं कि यह हर मुद्दे को हल नहीं करेगा, लेकिन यह बहुत कुछ हल करेगा।

जहां तक ​​इंटरफेस (गुण नहीं, चर, वर्ग जो प्रश्न से बाहर हैं) मैंने केवल एक खराब उदाहरण और कुछ जोरदार बयान देखे

अनिवार्य रूप से समस्या यह है कि nameof इंटरफेस के लिए हल करने की कोशिश कर रहा है, एक इंटरफ़ेस को एक स्ट्रिंग के साथ जोड़ना है, ताकि:

• जब भी आपके पास एक इंटरफ़ेस होता है तो आपको एक स्ट्रिंग मिलती है
• और एक स्ट्रिंग वाले प्रकार को प्राप्त करने की रिवर्स समस्या

थोड़ी सी असुविधा के साथ इसे आज जैसे ही सादे TS में किया जा सकता है:

type Wrapper<Type> = string & { '': [Type] };
function toWrapperFor<Type>(name: string) : Wrapper<Type> { return <any>name; }
const associations = {
    one: toWrapperFor<string>('one'),
    another: toWrapperFor<MyMegaControl>('another')
};

// ... later in code

class MyClass<Type>{
    constructor(private wrapper: Wrapper<Type>) {}
    take(value: Type): void { /*...*/ }
    toString(): string { return this.wrapper; }
}

const oneInstance = new MyClass(associations.one); // MyClass<string>
oneInstance.toString(); // 'one'
const anotherInstance = new MyClass(associations.another); // MyClass<MyMegaControl>
anotherInstance.toString(); // 'another'

@ एलेक्सी-बायकोव बिंदु यह है कि एक स्ट्रिंग को इंटरफ़ेस नाम के समान होने की गारंटी दी जाए। यह एक मामूली लाभ है, लेकिन फिर भी एक लाभ है। आपका उदाहरण ऐसा नहीं करता है। हमने पहले ही IoC के साथ उदाहरण के बारे में बात की है और इंटरफ़ेस नाम को रिफैक्टर करते समय स्ट्रिंग्स रिफैक्टर का होना कितना अच्छा होगा।

कुछ कारणों को सूचीबद्ध करने के लिए:

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

यही कारण हैं कि मैं इस समय सोच सकता हूं। ये ज़ोरदार या असमर्थित कथन नहीं हैं।

मैं उन प्रकारों के लिए कहूंगा कि केवल इंटरफ़ेस और प्रकार के उपनामों की अनुमति दी जानी चाहिए-कोई संघ/प्रतिच्छेदन/वस्तु/स्ट्रिंग/आदि नहीं। प्रकार। शायद कीवर्ड (जैसे number ) की भी अनुमति नहीं दी जानी चाहिए।

फिर से, पहिया को फिर से न लगाएं। सी # उदाहरण:

class A<T> { }
nameof(A<string>)
"A"

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

_ nameof _ की अत्यधिक आवश्यकता है यदि आप, मेरी तरह, एक NoSQL DB का उपयोग करते हैं और स्ट्रिंग निर्दिष्ट फ़ील्ड पर बहुत सारे प्रश्न करते हैं जो कि स्ट्रिंगलैंड के विचित्र दायरे में प्रवेश करते ही रिफैक्टरिंग, स्थिरता, त्रुटि-पकड़ने और स्वत: पूर्णता को ढीला कर देते हैं।

2014 के बाद से खुला यह मुद्दा वास्तव में कहावत का प्रतिनिधित्व करता है: बेहतर का दुश्मन सबसे अच्छा है

--आर

AngularJS उदाहरण, DI को कॉन्फ़िगर करना:

angular.module("news", ["ngRoute"])
    .controller("NewsIndexController", App.News.NewsIndexController) // nameof

और संदर्भ सेवाएं:

    .config(($routeProvider: ng.route.IRouteProvider) => {
        $routeProvider
            .when("/news", {
                controller: "NewsIndexController", // nameof
                templateUrl: "modules/news/views/index.html",
                controllerAs: "vm",
            })
    })

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

इस थ्रेड में वर्णित कई परिदृश्यों को https://github.com/Microsoft/TypeScript/pull/11929 में पेश किए गए keyof ऑपरेटर द्वारा नियंत्रित किया जाना चाहिए

keyof बिल्कुल बढ़िया है! लेकिन अभी भी नाम विशेषताओं के लिए कुछ चाहिए, जब डाटाबेसिंग: <input name={nameof(this.state.firstName)} />

हां, इस क्षेत्र में कुछ परिणाम देखकर अच्छा लगा। लेकिन keyof लिए उपयोग का मामला अलग है। आप अभी भी इसके नाम का संदर्भ नहीं दे सकते:

• गुण और सदस्य जैसे @Liero ने उल्लेख किया
• नाम टाइप करें, कमेंट देखें
• मापदंडों

@mhegazy

keyof अच्छा है, लेकिन यह काफी नहीं है। nameof तब भी _बेहद_ उपयोगी होगा जब उदाहरण के लिए ऑरेलिया में परिकलित गुणों की निर्भरता की घोषणा करना:

@computedFrom(nameof this.foo.bar)
// should compile to: @computedFrom("this.foo.bar")

या अमान्य फ़ंक्शन तर्कों के लिए त्रुटि संदेशों में:

throw new Error(`The value of ${nameof options.foo} must be positive`)
// should compile to: throw new Error(`The value of ${"options.foo"} must be positive`)

यह अंततः उन चीजों को रिफैक्टरिंग सुरक्षित बना देगा। वे वर्तमान में बनाए रखने के लिए एक बड़ा दर्द हैं, और जब आप उन्हें गड़बड़ करते हैं, तो यह चुपचाप होता है - आपको केवल प्रदर्शन समस्याएं मिलती हैं जिन्हें डीबग करना बेहद मुश्किल हो सकता है, और त्रुटि संदेश भ्रामक हो सकते हैं।

मैं देख रहा हूं कि ऊपर की कुछ पोस्ट इसके विभिन्न रूपों और जेनरिक आदि से संबंधित चिंताओं के बारे में बात करती हैं। मेरी राय में, यह यथासंभव सरल होना चाहिए - बस मुझे _exactly_ वह दें जो मैंने एक स्ट्रिंग के रूप में लिखा था। तो nameof Foo<Bar> को ठीक उसी के लिए संकलित करना चाहिए - "Foo<Bar>" । यदि जेनरिक की आवश्यकता नहीं है, तो उन्हें बाद में रेगेक्स का उपयोग करके हटाया जा सकता है। मैं वास्तव में नहीं देखता कि इसे इतना जटिल क्यों होना चाहिए।

या अगर यह अस्वीकार्य है, तो बस लानत जेनरिक को हटा दें, या सामान्य प्रकारों का समर्थन न करें - बस _कृपया_ इस पर पुनर्विचार करें। यह इतनी उपयोगी विशेषता है, और इसकी बहुत आवश्यकता है।

@ थॉमस-डार्लिंग अगर यह सी # परिभाषा की तरह कुछ भी था, तो nameof foo.bar "foo" , "foo.bar" ।

वैसे भी, आप सुरक्षित प्रकार प्राप्त कर सकते हैं, computedFrom अयोग्य नामों के लिए डेकोरेटर, का उपयोग करके

// computed-from.ts
export function computedFrom<K1 extends string, K2 extends string, K3 extends string>
  (prop1: K1, prop2: K2, prop3: K3): 
    (target: {[P in K1 | K2 | K3]}, key: string | number | symbol) => void;

export function computedFrom<K1 extends string, K2 extends string>
  (prop1: K1, prop2: K2): (target: {[P in K1 | K2]}, key: string | number | symbol) => void;

  export function computedFrom<K extends string>
    (prop: K): (target: {[P in K]}, key: string | number | symbol) => void;

और फिर इसका सेवन इस तरह करें

// welcome.ts
import { computedFrom } from './computed-from';

export class Welcome {
  firstName: string;

  lastName: string;

  @computedFrom('firstName', 'lastName') get fullName() {
    return `${this.firstName} ${this.lastName}`;
  }
}

योग्य नाम जैसे "foo.bar" भी संभव हैं।

@aluanhaddad

"foo.bar" जैसे योग्य नाम भी संभव हैं।

यह कुछ ऐसा है जिसे मैंने किसी तरह याद किया, विस्तृत करने की परवाह है?

मैं सोच रहा था कि एक टैग किए गए टेम्पलेट स्ट्रिंग घोषणा को अधिभारित करना संभव होगा, लेकिन आगे प्रतिबिंब पर मुझे नहीं लगता कि यह काम करेगा। मैं किसी भी भ्रम के लिए क्षमा चाहता हूँ।

ठीक है, तो नाम का परिचय देने के बजाय आप सभी पुस्तकालयों जैसे अपरिवर्तनीय और आदि का विस्तार करने का सुझाव देते हैं?

@aluanhaddad आपके द्वारा प्रदान किए गए ये उदाहरण "समस्या" को हल नहीं करते हैं जिसमें स्ट्रिंग के अंदर कोड संदर्भ हैं, जो स्वचालित रूप से या आसानी से बहुत अधिक अपरिवर्तनीय हैं। मेरे पीओवी में nameof का मुख्य लक्ष्य उन स्ट्रिंग को पुन: सक्रिय और खोजने योग्य बनाना है।

@fredgalvao यह #11997 बदल सकता है

@RyanCavanaugh यदि नई keyof सुविधा वास्तव में nameof लिए इस उपयोग के मामले को हल करती है, तो क्या आप एक उदाहरण प्रदान कर सकते हैं ... अधिमानतः टाइपस्क्रिप्ट प्लेग्राउंड का उपयोग करके यह साबित करने के लिए कि यह काम करता है? धन्यवाद!

स्क्रैच करें - मैंने इसे स्वयं करने की कोशिश की और यह लगभग पूरी तरह से काम करता है।

interface User {
    name: string;
    age: number;
}

var str1: keyof User;
var str2: keyof User;
var str3: keyof User;

str1 = "name"; // successful compile
console.log(str1);

str2 = "Age"; // compiler error due to typo
console.log(str2);

str3 = "age"; // successful compile
console.log(str3);

खेल का मैदान स्रोत

जब मैं बनाम कोड में Rename Symbol (F2) का उपयोग करने का प्रयास करता हूं, तो यह मेरी स्ट्रिंग का नाम nameof(mySymbol) सुविधा से अपेक्षा करता हूं।

इसके अतिरिक्त, मुझे फ़ंक्शन पैरामीटर के साथ उपयोग के मामले को संभालने का कोई तरीका नहीं दिख रहा है:

function log(name: string, age: number) {
    console.log(nameof(age), ' is ' , age);
}

तो keyof हमें उस तरह से 80% मिलता है जैसा मुझे लगता है लेकिन nameof अभी भी बेहतर है।

अद्यतन

मैंने यहां दोनों उपयोग के मामलों को कवर करने के लिए अलुआनहद्दाद का उदाहरण जोड़ा: खेल का मैदान स्रोत

फ़ंक्शन पैरामीटर नाम वश में करने के लिए एक कठिन जानवर हैं, क्योंकि रनटाइम पर वह नाम पूरी तरह से कुछ और हो सकता है, क्योंकि यह निश्चित मामलों में से एक है जिसे 99% पोस्ट-प्रोसेसर द्वारा छोटा/बदसूरत किया जाना है।

मेरा उपयोग-मामला सॉकेट के लिए है।

सॉकेट.आईओ का उपयोग करते हुए, सॉकेट एमिटर/रिसीवर स्ट्रिंग्स का उपयोग करके जुड़े हुए हैं।

तो वर्तमान में मैं यह लिख रहा हूँ:
(जहां showX() क्लाइंट और सर्वर साइड दोनों इंटरफेस कार्यान्वयन हैं)

public showLobby(): void {
    this.server.emit("showLobby");
 }

मैं क्या लिखना चाहता हूं:

public showLobby(): void {
    this.server.emit(nameof(this.showLobby));
 }

(मुझे पता है कि मैं this.showLobby.name लिख सकता हूं, लेकिन संकलन समय स्ट्रिंग रखना अच्छा होगा)

दूसरा कार्यान्वयन मुझे अपने इंटरफेस को दोबारा करने की अनुमति देगा, और क्लाइंट/सर्वर जादू स्ट्रिंग भी स्वचालित रूप से बदल जाएगी। जहाँ तक मैं देख सकता हूँ यह keyof के साथ संभव नहीं है।

जब मैं बनाम कोड में नाम बदलें प्रतीक (F2) का उपयोग करने का प्रयास करता हूं, तो यह मेरी स्ट्रिंग का नाम नहीं बदलता है, जिसे मैं nameof(mySymbol) सुविधा से अपेक्षा करता हूं।

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

पैरामीटर के लिए भी ऐसा ही किया जा सकता है, इसलिए लॉग उदाहरण अन्य के साथ-साथ काम करता है और इस सुविधा के वास्तव में शक्तिशाली पहलुओं में से एक को भी प्रदर्शित करता है।

function log<K extends keyof User>(name: K, value: User[K]) {
  console.log(name, ' is ', value);
}

const user: User = {
  name: 'Jill',
  age: 50
};

log(str1, user[str1]); // OK
log(str3, user[str3]); // OK
log(str3, user[str1]); // Error
log('age', user.name); // Error

गहरा सहसंबद्ध f- सीमा।

@aluanhaddad मुझे नहीं लगता कि आपका log उदाहरण ठीक उसी तरह काम करता है जैसा आप वर्णन करते हैं। मेरी समझ यह है कि निम्नलिखित बिल्कुल ठीक होगा:

function log<K extends keyof User>(name: K, value: User[K]) { }

const user: User = {
  firstName: 'John',
  lastName: 'Doe'
};

log('firstName', user.lastName);  // OK, unfortunately

ऐसा इसलिए है क्योंकि K का अनुमान 'firstName' और इसलिए, U[K] का अनुमान string , जो lastName संतुष्ट करता है।
आपका उदाहरण केवल इसलिए अच्छा है क्योंकि प्रत्येक संपत्ति का एक अलग प्रकार था।

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

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

मेरे लिए और भी महत्वपूर्ण टूल है _Find all Reference_, जो बस काम नहीं करता है। इसका स्थानापन्न एक सादा पाठ है _Find_, लेकिन (ए) आपको कभी भी _Find Reference_ का उपयोग नहीं करने की आदत डालने की आवश्यकता है, जो शर्म की बात है और (बी) सामान्य नामों के लिए, _Find_ बेहद शोर है और बहुत सारे झूठे सकारात्मक को बदल देता है।

#11997 के लिए वोट करें!

@RyanCavanaugh : उदाहरण के लिए अपरिवर्तनीय.js के साथ keyof कैसे मदद कर सकता है? आप सभी अपरिवर्तनीय वर्गों का विस्तार नहीं कर सकते। nameof उसमें मदद कर सकता है। जहाँ तक Angular2 टाइपस्क्रिप्ट के साथ जाता है और प्रदर्शन के लिए यह अपरिवर्तनीय.js के साथ भी जाता है, nameof आवश्यक है ।

@RyanCavanaugh : शायद फिर से खोलने का समय? हमने पर्याप्त उपयोग के मामले एकत्र किए हैं जहां keyof मदद नहीं करता है। धन्यवाद

मैंने इसे अभी के लिए करने के लिए एक गल्प कार्य को हैक किया। इसे टाइपस्क्रिप्ट कंपाइलर से पहले चलाएं। अगर किसी को दिलचस्पी है:

शायद उत्पादन के लिए सुरक्षित नहीं है।

var replace = require('gulp-string-replace');

gulp.task("nameof", function () {
    var regexReplace = function (match) {
        // nameof(foo.bar) => foo.bar
        var propName = match.slice(7, -1).trim();
        // foo.bar => bar (also works if no . present)
        var endElement = propName.split(/[.]+/).pop();
        return '"' + endElement + '"';
    };

    return gulp.src("./src/**/*.ts")
        .pipe(replace(/nameof\s*\([^\)]*\)/, regexReplace))
        .pipe(gulp.dest("./nameof"));
});

@CoenraadS यदि आप ऐसा करने के लिए एक गल्प कार्य का उपयोग कर रहे हैं तो आपको ts-nameof में रुचि हो सकती है क्योंकि अधिकांश काम पहले से ही किया जा चुका है (मैंने पहले इस धागे में इसका उल्लेख किया था)। मैं पिछले कुछ समय से टाइपप्रति में nameof का उपयोग कर रहा हूं।

समझ में नहीं आता, अगर किसी ने ts-nameof, gulp टास्क किया - ts टीम के लिए ऐसी समस्या क्यों है!

@ vytautas-pranskunas- keyof के बारे में इस धागे में टिप्पणियों के आधार पर, मैंने अपरिवर्तनीय में चाबियों के सही उपयोग को लागू करने के लिए ऐसा किया:

export interface IAppState {
    isConnectedToServer: boolean
}

const checkKey = <T>(key: keyof T) => key;

export const reducer: Reducer<IAppState> = (state = initialState, action: KnownAction) => {
    switch (action.type){
        case 'CONNECTED_TO_SERVER':
            return state.set(checkKey<IAppState>('isConnectedToServer'), true)
        case 'DISCONNECTED_FROM_SERVER':
            return state.set(checkKey<IAppState>('isConnectedToServer12345'), false) //Compile time error :)

यकीनन, यह nameof की तुलना में अधिक वर्बोज़ होगा, और रिफैक्टरिंग करते समय आपको कोई मदद नहीं मिलती है, लेकिन कम से कम आपको संकलन समय की जाँच मिलती है।

@paulinfrancis हाँ ऐसा ही किया जा सकता है। लेकिन फिर भी मुख्य प्रश्न अनुत्तरित रहता है: ऐसा स्पष्ट व्यवहार प्राप्त करने के लिए समुदाय को सभी प्रकार के सहायक कार्य और हैक क्यों करने चाहिए और ts टीम इसे लागू करने से मना क्यों करती है?

और फिर रिफैक्टरिंग समर्थन है, जो हमें keyof साथ भी नहीं मिलेगा। मैं नए खोजशब्दों को पेश करने के लिए आपकी अनिच्छा को समझता हूं और सम्मान करता हूं, लेकिन यह एक मौलिक भाषा विशेषता है जिसकी अत्यंत आवश्यकता है, और इसमें स्पष्ट और निर्विवाद उपयोग के मामले हैं - और इसकी कमी से दैनिक आधार पर गंभीर दर्द और खराब कीड़े दोनों होते हैं। इसे फिर से खोलने के लिए और क्या चाहिए?

हर 3-4 महीने में मैं इस धागे पर वापस आता हूं और nameof() ऑपरेटर को शामिल न करने की जिद से एक बार फिर निराश हो जाता हूं। यह वास्तव में बहुत से लोगों के लिए एक बड़ी परेशानी है, और इसे किसी अन्य उपयोग के मामले में शामिल नहीं करना अविश्वसनीय है।

हर कोई इस बात से सहमत लगता है कि इसे कमोबेश ठीक उसी तरह काम करना चाहिए जैसे C# करता है।

मुझे लगता है कि हमें एक विरोध का आयोजन करना चाहिए - रेडमंड और धरना एमएस मुख्यालय तक ड्राइव करें ... क्योंकि मैं गंभीरता से विचारों से बाहर हूं।

पर्याप्त लोग बकवास नहीं कर रहे हैं, ज्ञात समस्या के बारे में नए मुद्दे बनाना सबसे अच्छा काम करता है

मैंने ट्रांसफ़ॉर्म एपीआई की जाँच नहीं की है, लेकिन मुझे लगता है कि ट्रांसफ़ॉर्म में nameof को लागू करना अपेक्षाकृत आसान होगा। ट्रांसफॉर्म को कंपाइलर के साथ भी शिप किया जा सकता है, लेकिन इसका आधिकारिक हिस्सा नहीं। इस दृष्टिकोण से, इसे समय से पहले लागू न करना टीम की ओर से वास्तव में एक चतुर चाल है।

@gcnew क्या आसान है? nameof([put valid identifier here]) -> स्ट्रिंग के रूप में उस पहचानकर्ता का अंतिम भाग। मेरा मतलब है कि यह एक गौरवशाली मैक्रो है। वास्तव में, काम पर हम बस एक फ़ंक्शन जोड़ने वाले हैं nameof(thing:any) जो ठीक उसी तरह से बदल जाता है जैसा @frodegil ने रेगेक्स या जो कुछ भी पोस्ट-कंपाइल पर ऊपर सुझाया था। मुझे यकीन है कि कुछ किनारे के मामले हैं जिन्हें तकनीकी रूप से कुछ और विचार की आवश्यकता हो सकती है, लेकिन यह मूल रूप से इस धागे में व्यक्त सभी उपयोग मामलों को कवर कर रहा है। जादू के तार और प्रतिबिंब की कमी से त्रस्त भाषा में इसे nameof() जोड़ने के लिए यह केवल समझ की एक अनंतता होगी - इसके बजाय हमें keyof() । हथेली। चेहरा।

@gleno keyof एक बहुत ही उपयोगी विशेषता है। तथ्य यह है कि यह जिन समस्याओं को हल करता है वे nameof से जो लोग चाहते हैं उससे अलग हैं, एक और कहानी है।

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

@gcnew मेरी समझ है कि परिवर्तन मौजूदा सिंटैक्स से हैं -> मौजूदा सिंटैक्स, nameof नया सिंटैक्स है इसलिए यह गायब है, मुझे आशा है कि मैं गलत हूं

@ एलेक्सी-बायकोव हां, मुझे भी ऐसा ही लगता है। हालाँकि यदि आपके पास कोई फ़ंक्शन घोषणा है जैसे:

declare function nameof(x: any): string;

और एक परिवर्तन जो सभी वैश्विक nameof इनवोकेशन को इसके तर्क के साथ बदल देता है, इसे काम करना चाहिए।

संपादित करें: ऐसा समाधान पर्याप्त नहीं होगा जहां एक स्ट्रिंग अक्षर की अपेक्षा की जाती है। फिर भी यह एक अच्छा पहला कदम है और जितने अधिक कंपाइलर एपीआई उपलब्ध होंगे उतना ही इसे बेहतर बनाया जा सकता है।

@gcnew : यदि यह नाम के परिदृश्यों के लिए एक आधिकारिक समाधान होने वाला है, तो कृपया इसे दस्तावेज़ीकरण में लिखें, उदाहरण के लिए यहां: https://www.typescriptlang.org/docs/handbook/gulp.html

@gcnew यदि आप रोसलिन को देखते हैं, तो विस्तार बिंदु डायग्नोस्टिक्स, फिक्स और रिफैक्टरिंग हैं जो विकास के दौरान सहायता प्रदान करते हैं और उनमें से किसी का भी उपयोग करने का कोई जोखिम नहीं है। आखिरी चीज जो मैं करना चाहता हूं वह यादृच्छिक पैकेज जोड़ना है जो बिल्ड पाइपलाइन के हैक्स के साथ करता
और फिर "हम टाइपस्क्रिप्ट 2.x में अपग्रेड नहीं कर सकते" जैसी समस्याओं के साथ समाप्त होते हैं, क्योंकि "नाम का पैकेज" 0.1.2 अभी तक इसका समर्थन नहीं करता है, इसलिए 1) हमें इंतजार करना होगा या 2) नाम के सभी उपयोगों को हटा दें हमारे कोड और इसे ढीला; या 3) इसे स्वयं पुन: लागू करें और इसे हमेशा के लिए बनाए रखें" कुछ महीनों में।

@ पीटर-जुहाज़ जो आपको इसे npm से डाउनलोड करता है? इसे स्वयं बनाएं और अपनी 24/7 ग्राहक सेवा बनें

परिवर्तन एपीआई का इन परिस्थितियों से बहुत कम लेना-देना है

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

यह हमें दो विकल्पों के साथ छोड़ देता है:

• एक ईसीएमएस्क्रिप्ट प्रस्ताव बनाएं और आशा करें कि यह कर्षण प्राप्त करेगा
• सार्वजनिक Transfroms API का उपयोग करें और एक अच्छा सन्निकटन प्राप्त करें

पहले विकल्प में वर्षों लगेंगे (यदि यह कभी स्वीकृत हो जाता है), दूसरा पर्याप्त सभ्य होना चाहिए। मुझे टीएस एपीआई का उपयोग करने का कोई अनुभव नहीं है, लेकिन मैं उनसे स्थिर और पिछड़े-संगत होने की अपेक्षा करता हूं, इस प्रकार _nameof package_ भी स्थिर होना चाहिए।

मैं मारिन से असहमत हूं, नामोफ़ एक भाषा विशेषता नहीं है, यह केवल सक्षम बनाता है
टाइप-चेकिंग (कीऑफ के समान), एक बार संकलित नाम गायब हो जाता है और इसका
तर्क को एक स्ट्रिंग के रूप में छोड़ दिया जाता है।
मैं यह नहीं देखता कि अगर keyof नहीं है तो इसे एक्मास्क्रिप्ट का हिस्सा बनने की आवश्यकता क्यों होगी।

14 फरवरी, 2017 19:19 को, "मारिन मारिनोव" नोटिफिकेशन @github.com ने लिखा:

@ पीटर-जुहास https://github.com/Peter-Juhasz मैं आपके लिए महसूस करता हूं और मैं करता हूं
सहमत हैं कि nameof उपयोगी होगा और सुरक्षा जोड़ देगा। हालांकि टाइपस्क्रिप्ट है
ईसीएमएस्क्रिप्ट मॉडलिंग के बारे में, एक नई बेहतर भाषा नहीं बनाना। विशेषताएं
जैसे कीओफ़ विशुद्ध रूप से स्तर का स्तर है, इसलिए वे प्राप्त कर रहे हैं
क्रियान्वित किया। और उनके लिए भी टीम की ओर से विरोध है
एक कीवर्ड आवंटित करें। इसके विपरीत, nameof सख्ती से एक अभिव्यक्ति स्तर है
निर्माण। मुझे नहीं लगता कि टीम इसे लागू करने के लिए कभी आश्वस्त होगी,
जब तक कि यह ईसीएमएस्क्रिप्ट स्पेक में न हो। मुझे खुद का विचार पसंद नहीं है
पहचानकर्ता के नाम पर मैला ढोना।

यह हमें दो विकल्पों के साथ छोड़ देता है:

• एक ईसीएमएस्क्रिप्ट प्रस्ताव बनाएं और आशा करें कि यह कर्षण प्राप्त करेगा
• सार्वजनिक Transfroms API का उपयोग करें और एक अच्छा सन्निकटन प्राप्त करें

पहले विकल्प में वर्षों लगेंगे (यदि यह कभी स्वीकृत हो जाता है), दूसरा
पर्याप्त सभ्य होना चाहिए। मुझे TS API का उपयोग करने का कोई अनुभव नहीं है, लेकिन
मैं उनसे स्थिर और पिछड़े-संगत होने की अपेक्षा करता हूं, इस प्रकार nameofपैकेज भी स्थिर होना चाहिए।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने इस थ्रेड की सदस्यता ली है।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/Microsoft/TypeScript/issues/1579#issuecomment-279790055 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/ABOZ9c-85P3x5AMakVDuxlNkH56me3POks5rcfAYgaJpZM4DNVgi
.

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

अगर दिलचस्पी है तो मुझे सम्मानित करें, हम एक प्रस्ताव लिख सकते हैं और सबसे खराब स्थिति में प्री-प्रोसेसर।
(समय और प्रेरणा की अनुमति)

--आर

@gcnew :
1. nameof ES युक्ति में कभी नहीं होगा । मैं ऐसा कहने के लिए बहुत आश्वस्त हूं, क्योंकि एक्मास्क्रिप्ट में नाम का ज्यादा मतलब नहीं है। यहां बताया गया है: जावास्क्रिप्ट में गतिशील टाइपिंग के कारण, nameof(myObject.MyProperty) बिल्कुल "myProperty" जैसा ही है। दोनों मूल रूप से "जादू तार" हैं। जावास्क्रिप्ट में वर्बोज़ नेमऑफ़ सिंटैक्स का उपयोग करने का कोई कारण नहीं है। या आप जावास्क्रिप्ट में nameof का उपयोग करने का कोई लाभ देखते हैं?

जैसा कि @RyanCavanaugh ने उल्लेख किया है, केवल मानकीकृत ES सुविधाएँ या सुविधाएँ जो ES कल्पना में कभी नहीं होंगी, उन्हें भ्रम से बचने के लिए टाइपस्क्रिप्ट के लिए माना जा सकता है जैसे कि यह मॉड्यूल के साथ खुश होता है। यह दूसरा मामला है।

1. टाइपस्क्रिप्ट का मूल उद्देश्य स्थिर टाइपिंग प्रदान करना और बेहतर रिफैक्टरिंग टूल की अनुमति देना है। डेटा बाइंडिंग परिदृश्यों में संपत्ति के नामों की बहुत बार आवश्यकता होती है और

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

@Liero आप कभी नहीं जान सकते कि भविष्य के संस्करणों में वैध पहचानकर्ता का उपयोग किया जाएगा या नहीं। इसका उपयोग ईसीएमए द्वारा सीधे तौर पर नहीं किया जा सकता है या यहां पर चर्चा किए गए उद्देश्य के लिए नहीं किया जा सकता है, लेकिन इसका उपयोग ब्राउज़र एपीआई में हो सकता है। एक वैश्विक फ़ंक्शन nameof(node: Node): string | undefined पर विचार करें जो DOM नोड की name विशेषता को पढ़ता है। क्या इस तरह के समारोह को कभी मानकीकृत किया जाएगा? शायद नहीं _यह एक_ लेकिन हो सकता है कि प्रमाणपत्र या Symbol s से संबंधित हो। बात यह है कि nameof को एक कीवर्ड के रूप में उधार नहीं लिया जा सकता है। स्थानीय चर नामों के लिए पहले से ही इसका उपयोग कर रहे कोड हैं और भविष्य के एपीआई भी इसका इस्तेमाल कर सकते हैं। ईसीएमएस्क्रिप्ट विनिर्देश से अलग होने पर यह एक दुर्भाग्यपूर्ण ब्रेकिंग परिवर्तन होगा।

समाधान या तो nameof को प्रकार के स्तर तक उठाना है, या nameof को एक वैकल्पिक प्री/पोस्ट प्रोसेसिंग चरण के रूप में लागू करना है, जो आधिकारिक भाषा का हिस्सा नहीं है।

एक प्रकार-स्तर, पूरी तरह से मिटाने योग्य nameof हो सकता है:

declare const options: {
    easing?: string,
    duration: number
};

if (!options.easing) {
    throw new Error(<nameof options.easing> 'easing');
}

स्तर

nameof(path.to.identifier) संकलन प्रक्रिया से कभी नहीं बचेगा। अंतिम संकलित कोड में nameof देखना निश्चित रूप से है और बिल्कुल वैसा नहीं है जैसा हर कोई चाहता है। हम चाहते हैं कि यह गायब हो जाए, और स्ट्रिंग को पीछे छोड़ दें "identifier" , जो nameof के कार्यान्वयन को एक संकलन/प्रकार के स्तर के रूप में ठीक वही बनाता है जो इसे होना चाहिए। के बीच एकमात्र अंतर:

type AliasToUnion = A | B;
तथा
nameof(object.property)

परिणाम है: एक एक खाली स्ट्रिंग देता है और दूसरा एक गैर-रिक्त स्ट्रिंग देता है। दोनों प्रकार के स्तर की संरचनाएं हैं, और संकलन पूरा होने के बाद दोनों का खोल गायब हो जाता है।

टक्कर

यदि अब तर्क यह है कि हम टाइपस्क्रिप्ट के nameof और भविष्य के एक्मा के nameof के बीच एक कीवर्ड टकराव का जोखिम नहीं उठा सकते हैं, तो मैं कहूंगा कि एक ही तर्क बहुत कुछ टाइपस्क्रिप्ट पर लागू होता है जो कि नहीं है es8 ड्राफ्ट के साथ प्रतिच्छेदन में, जो मूल रूप से बहुत प्रकार का सामान है , इस प्रकार यह तर्क काफी फर्जी है।

इच्छा

यहां तक ​​​​कि अगर हम कीवर्ड के रास्ते पर नहीं जाते हैं, तो यह मेरे लिए बहुत अधिक है कि मुझे अभी भी ऐसा क्यों लगता है कि ऐसा करने के लिए यह बेहतर टाइपस्क्रिप्ट का काम है (चाहे वह एक परिवर्तन हो, एक संकलन स्तर का कार्य हो, एक प्रकार की संरचना, एक एक्मा प्रस्ताव, आदि) :

टाइपस्क्रिप्ट का मूल उद्देश्य स्थिर टाइपिंग प्रदान करना और बेहतर रिफैक्टरिंग टूल की अनुमति देना है। डेटा बाइंडिंग परिदृश्यों में संपत्ति के नामों की बहुत बार आवश्यकता होती है और टाइप सुरक्षित तरीके से ऐसा करना ठीक वैसा ही है जैसा आप टाइपस्क्रिप्ट से उम्मीद करते हैं।

सुझाव

<nameof options.easing> 'easing'

ऐसा लगता है कि यह लगभग ऐसा करता है, लेकिन हमें मैन्युअल रूप से उस जादुई स्ट्रिंग को मैन्युअल रूप से दोबारा करना होगा, केवल एक ही अंतर के साथ कि हमारे पास संकलक हमें बताएगा कि इसका मान पहचानकर्ता के वास्तविक नाम का प्रतिनिधित्व नहीं करता है . यह एक है refactor->compile->see_error->go_back_and_properly_refactor एक के बजाय प्रवाह refactor_properly एक। इसके साथ, मैं इस प्रस्ताव के बजाय अधिक पूर्ण संस्करण पर जोर देना चाहूंगा। अब, @gcnew , अगर हम <> एक ऐसी संरचना बना सकते हैं जिसे डालने के लिए किसी मूल्य की आवश्यकता नहीं है, तो यह बहुत बढ़िया होगा (मुझे नहीं लगता कि हम एटीएम कर सकते हैं)।

दोस्तों, nameof निश्चित रूप से आवश्यक है, जबकि 90% सक्षम वर्कअराउंड है जो केवल थोड़ा अतिरिक्त टाइपिंग लेता है:

type NamesOf<T> = { [P in keyof T]: P }
interface Data {
    name: string;
    value: number;
}
const propertyNames: NamesOf<Data> = {
    name: 'name,' // <-- not a magic string anymore, CAN ONLY BE `name`
    value: 'value' // <-- not a magic string anymore, CAN ONLY BE `value`
}

@gcnew :

एक वैश्विक फ़ंक्शन नाम पर विचार करें (नोड: नोड): स्ट्रिंग | अपरिभाषित

मौजूदा जावास्क्रिप्ट फाइलों में उपयोग - कोई समस्या नहीं। टाइपस्क्रिप्ट में संघर्षों से बचा जा सकता है:

var _nameof = window.nameof; //problem solved

बीटीडब्लू, जावास्क्रिप्ट में फ़ंक्शन को शायद nameOf . कहा जाएगा

@fredgalvao : आपका सुझाव: <nameof options.easing> पहले से ही JSX, सम्मान TSX के साथ संघर्ष करता है

@Liero वह मेरा सुझाव नहीं था, मैं सिर्फ @gcnew के सुझाव पर टिप्पणी कर रहा था।

ठीक है, क्या होगा अगर टाइपसाइड नेमऑफ़ ऑपरेटर था?

कुछ ऐसा दिखाई देगा:

const obj = {x:1};
function abc(thing:nameof(obj.x)){ }

जो बिल्कुल जैसा व्यवहार करेगा

function abc(thing:"x"){ }

यह nameof(accessor)->string जितना साफ नहीं है, लेकिन मुझे लगता है कि यह काफी उपयोगी हो सकता है।

मैं nameOf को केवल एक संकलन-समय कीवर्ड के रूप में मानता हूं, और इसका कोई रनटाइम या वैश्विक उपयोग नहीं देख सकता (कभी नहीं कहें, लेकिन इसकी संभावना नहीं है, आईएमओ - इसे TSNameOf , और यह है और भी असंभव)

क्या हमें टकराव से डरना चाहिए? यदि, या कब, EcmaScript एक ऐसी भाषा बन जाती है जिसे भविष्य में nameOf कीवर्ड की आवश्यकता होती है, तो मुझे लगता है कि यह अब तक विकसित हुआ है, और TS की सभी विशेषताओं को अपनाया है ताकि हमें अब TS की आवश्यकता न पड़े।

nameOf TS में ठीक उसी तरह व्यवहार करना चाहिए जैसे C# में nameOf

सी # (v5) चश्मा:

नाम का व्यंजक एक स्थिरांक है। सभी मामलों में, nameof(...) का मूल्यांकन एक स्ट्रिंग बनाने के लिए संकलन-समय पर किया जाता है। इसके तर्क का रनटाइम पर मूल्यांकन नहीं किया जाता है, और इसे अगम्य कोड माना जाता है (हालाँकि यह "पहुँच योग्य कोड" चेतावनी का उत्सर्जन नहीं करता है)।

मैंने अब तक अपने टीएस/कोणीय कोड में स्ट्रिंग-अक्षरों को "रीफैक्टरिंग" करने में बहुत अधिक समय बिताया है। आखिरकार, टाइपस्क्रिप्ट का मुख्य उद्देश्य दृढ़ता से टाइप किया गया विकल्प होना है, है ना?

जल्दी करें, TS के अप्रचलित होने से पहले कंपाइल-टाइम nameOf कीवर्ड शामिल करें :)

निम्नलिखित की तरह एक कस्टम nameOf फ़ंक्शन के बारे में क्या?

declare const options: {
    easing: string,
    duration: number,
};

function nameOf<T, K extends keyof T>(_: T, key: K) {
    return key;
}

nameOf(options, 'easing'); // 'easing'
nameOf({ options }, 'options'); // options

पुनश्च: keyof रिफैक्टरिंग को https://github.com/Microsoft/TypeScript/issues/1997 द्वारा ट्रैक किया जाता है

मेरे पास परिवर्तन एपीआई (#13940) के साथ कार्यान्वित nameof एक बहुत ही सरल कार्यान्वयन है जो मैंने आज सुबह जल्दी किया (देखें ts-nameof की यह शाखा - विशेष रूप से यह फ़ाइल और इस फ़ाइल में उपयोग की गई)।

अगर हमारे पास संकलन करते समय परिवर्तनों से पहले और बाद में बाहरी पथ निर्दिष्ट करने के लिए tsconfig.json में कोई तरीका था, तो मुझे लगता है कि यह संकलक में सीधे कार्यान्वयन से अधिक शक्तिशाली होगा।

संपादित करें: पुस्तकालय अब बेबेल और टाइपप्रति संकलक का समर्थन करता है।

मेरे दो सेंट के लिए, मैं इनवर्सिफाई के साथ बाइंडिंग में तारों से छुटकारा पाने के लिए पूरी तरह से नाम देखना पसंद करूंगा।

मैं भी बस इस पर गौर कर रहा था। मैं उम्मीद कर रहा था कि यह अब तक लागू की गई एक स्पष्ट विशेषता होगी। मैं एक कस्टम इवेंट सेटअप (ब्ला ब्लै ब्लै;)) में विधि नामों से ईवेंट स्ट्रिंग नाम प्राप्त करने की उम्मीद कर रहा था, अन्य चीजों के साथ (जैसे नामस्थान संग्रहीत करना और मेटाडेटा टाइप करना, आदि)। उम्मीद है, हमें इस पर और 2 साल तक चर्चा करने की आवश्यकता नहीं पड़ेगी।

मुझे यह भी देखना अच्छा लगेगा। मैं कुछ ASP.NET AJAX विरासत कोड के साथ काम कर रहा हूं और सामान से निपटना है जैसे:

DerivedClass.registerClass( "DerivedClass", BaseClass );

इसके बजाय ऐसा करना वाकई अच्छा होगा:

DerivedClass.registerClass( nameof( DerivedClass ), BaseClass );

वर्तमान में, DerivedClass नाम बदलने से कोड टूट जाएगा।

nameof() Immutable.js Record का उपयोग करने के लिए अच्छा होगा।

यह कोड

class MyRecord extends Record({value: ""}) {
  readonly value: string;

  withValue(newValue: string) {
    return this.set("value", newValue) as this;
  }
}

की तरह फिर से लिखा जा सकता है

class MyRecord extends Record({value: ""}) {
  readonly value: string;

  withValue(newValue: string) {
    return this.set(nameof(this.value), newValue) as this;
  }
}

, जो नाम बदलने के लिए सुरक्षित है।

वर्ग या चर के नाम के लिए संभावित समाधान:

function nameof<T, P extends keyof T>(descriptor: {[P in keyof T]?: T[P]; }): P
{
    for(var key in descriptor) {
        if(descriptor.hasOwnProperty(key)) {
            return key as P;
        }
    }
}

class Test { }
var test= ""

var x = nameof({ Test })  // x: "Test" = "Test"
var y = nameof({ test })  // y: "test" = "test"

@jankaspar क्या आपके उदाहरण के साथ Test.foo होना संभव है जहां टेस्ट-क्लास, फू-क्लास प्रॉपर्टी?

@vytautas-pranskunas-
नहीं, इसके लिए आप मैप किए गए प्रकारों का उपयोग करना बेहतर समझते हैं। कुछ इस तरह:

class Test {
    foo: string
}

function propertyName<T>(name: keyof T){ 
    return name;
}
propertyName<Test>("foo") 
propertyName<Test>("bar")  // error

ध्यान दें कि यह सही नहीं है। मुझे लगता है कि जैसी चीजों का उपयोग कर की कोशिश की है और यह विफल हो गया क्योंकि इंटरफेस बहुत जटिल थे, और संकलक, बजाय पैदा करने की "field1" | "field2" के लिए keyof T , जैसे उत्पन्न कुछ any , और कुछ भी संकलित होगा।

शुक्रिया!
रीडल द्वारा स्पार्क

कक्षाओं और इंटरफेस के साथ इसे कैसे करें इस पर कोई सहमति है? मैं देखता हूं कि मैं सिर्फ keyof कैसे कर सकता हूं लेकिन मूल रूप से मैं nameof(type) का उपयोग करना चाहता हूं ताकि यह लॉगिंग को आसान बना दे, उदाहरण के लिए, LogManager.getLogger(nameof(MyClass))

@niemyjski यह मानक जावास्क्रिप्ट के साथ उपलब्ध है।

class MyClass {
   hello(n) { return 'hello ' + n; }
}
console.log(MyClass.name);

फंक्शन देखें।नाम

@styfle कोड को

@dpogue अधिकांश मिनीफायर नाम मैंगलिंग को अक्षम करने का विकल्प देते हैं (विश्व स्तर पर, या एनोटेटेड फ़ंक्शंस/कक्षाओं के लिए); जो संतुष्ट हो सकता है?

कुछ लोगों के लिए यह आश्चर्यजनक भी हो सकता है कि nameof(MyClass) != MyClass.name (छोटा मामले में)

साथ ही, #8 और #16037 पर नज़र रखने के लिए कुछ संबंधित चर्चाएं हो सकती हैं

हाँ, हमें कुछ विश्वसनीय चाहिए...

धन्यवाद
-ब्लेक नीमीज्स्की

बुधवार, 19 जुलाई, 2017 को पूर्वाह्न 11:47 बजे, इयान मैकलियोड नोटिफिकेशन @github.com
लिखा था:

@dpogue https://github.com/dpogue अधिकांश मिनीफायर एक विकल्प देते हैं
नाम मैंगलिंग अक्षम करें (विश्व स्तर पर, या एनोटेटेड फ़ंक्शंस/कक्षाओं के लिए); वह
संतुष्ट हो सकता है?

साथ ही, #8 https://github.com/Microsoft/TypeScript/issues/8 और #16037
https://github.com/Microsoft/TypeScript/issues/16037 में कुछ हो सकता है
नजर रखने के लिए संबंधित चर्चा

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/Microsoft/TypeScript/issues/1579#issuecomment-316447179 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AA-So1aBKzLHIsS4-wYSeZmtNOf55B9Rks5sPjMYgaJpZM4DNVgi
.

@nevir और @dpogue यह समाधान काम नहीं कर सकता है जहां आप इंटरफ़ेस द्वारा हल करने का प्रयास कर रहे हैं, न कि डीआई के माध्यम से एक ठोस प्रकार - यानी रनटाइम पर इंटरफ़ेस नाम उपलब्धता के लिए हल नहीं करता है।

मुझे हाल ही में कुछ इस तरह की आवश्यकता मिली है क्योंकि keyof योग्य पहचानकर्ताओं को अनुमति नहीं देता है।

चूंकि एपीआई मैंने अपने उदाहरण में उपयोग किया था, अब बिंदीदार पथ स्ट्रिंग्स का उपयोग करके योग्य नामों का समर्थन करता है, जो वृद्धि मैं अपनी प्रकार की सुरक्षा में सुधार के लिए उपयोग कर रहा था:

export function computedFrom<K1 extends string, K2 extends string>
  (prop1: K1, prop2: K2): (target: {[P in K1 | K2]}, key: string | number | symbol) => void;

  export function computedFrom<K extends string>
    (prop: K): (target: {[P in K]}, key: string | number | symbol) => void;

अब अपनी क्षमताओं को व्यक्त नहीं कर सकता।

इतने समय के बाद भी, TS के पास अभी भी MAGIC STRINGS को समाप्त करने के लिए (जैसे nameof ) कोई तंत्र नहीं है?

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

+1

यह एक उपयोगी विशेषता होगी

तो क्या कहानी है दोस्तों, क्या ऐसा हो रहा है?

जैसा कि @jakkaj ने पहले उल्लेख किया था, यह inversify के साथ उपयोग करने के लिए वास्तव में एक शानदार विशेषता

यहां एक उदाहरण दिया गया है कि जब आप इंटरफेस का उपयोग करते हैं तो आपको _currently_ क्या करना होता है:

interface Weapon {
    hit(): string;
}

// Define an object that contains all of the type 
// symbols so that we only use magic strings once.
let TYPES = {
    Weapon: Symbol("Weapon")  // Magic String! Oh No!
};

@injectable()
class Ninja {
    constructor(@inject(TYPES.Weapon) weapon: Weapon) { }
}

nameof ऑपरेटर के साथ, आप कम से कम जादू स्ट्रिंग से छुटकारा पा सकते हैं, लेकिन आप उस ऑब्जेक्ट से भी छुटकारा पा सकते हैं जिसमें सभी प्रकार के प्रतीक हैं:

interface Weapon {
    hit(): string;
}

@injectable()
class Ninja {
    constructor(@inject(Symbol(nameof(Weapon))) weapon: Weapon) { }
}

मेरा मानना ​​​​है कि स्ट्रिंग्स का उपयोग यह घोषित करने के लिए भी किया जा सकता है कि क्या इंजेक्ट किया गया है, इसलिए आप इसके लिए कंस्ट्रक्टर को भी बदल सकते हैं:

@injectable()
class Ninja {
    constructor(@inject(nameof(Weapon)) weapon: Weapon) { }
}

@reduckted

इंटरफ़ेस का उपयोग करते समय आपको वर्तमान में क्या करना है इसका एक उदाहरण यहां दिया गया है:

interface Weapon {
    hit(): string;
}

// Define an object that contains all of the type 
// symbols so that we only use magic strings once.
let TYPES = {
    Weapon: Symbol("Weapon")  // Magic String! Oh No!
};

@injectable()
class Ninja {
    constructor(@inject(TYPES.Weapon) weapon: Weapon) { }
}

दरअसल, यह कोई जादू की डोरी नहीं है। आप ठीक वैसे ही लिख सकते हैं

const types = { // this should be frozen in real code.
  Weapon: Symbol()
};

और निहितार्थ समान होंगे (सभी उपभोग करने वाले कोड को Weapon types ऑब्जेक्ट की संपत्ति का संदर्भ देना चाहिए)।

नाम के ऑपरेटर के साथ, आप कम से कम जादू स्ट्रिंग से छुटकारा पा सकते हैं, लेकिन आप उस ऑब्जेक्ट से भी छुटकारा पा सकते हैं जिसमें सभी प्रकार के प्रतीक हैं:

interface Weapon {
    hit(): string;
}

@injectable()
class Ninja {
    constructor(@inject(Symbol(nameof(Weapon))) weapon: Weapon) { }
}

यह संभवतः वांछित प्रभाव नहीं होगा क्योंकि हर बार Symbol कहा जाता है यह एक नया अद्वितीय मूल्य बनाता है

Symbol("x") === Symbol("x") // false

मेरा मानना ​​​​है कि स्ट्रिंग्स का उपयोग यह घोषित करने के लिए भी किया जा सकता है कि क्या इंजेक्ट किया गया है, इसलिए आप इसके लिए कंस्ट्रक्टर को भी बदल सकते हैं:

@injectable()
class Ninja {
    constructor(@inject(nameof(Weapon)) weapon: Weapon) { }
}

यदि प्रस्तावित कार्यक्षमता C# के nameof ऑपरेटर के अनुरूप है, तो इसका परिणाम @inject("Weapon") , जो छिपी हुई वैश्विक निर्भरता और टोकन टकराव का परिचय देगा।

कुछ इस तरह

interface Weapon {
    hit(): string;
}
const Weapon = Symbol();
export default Weapon;

बेहतर लगता है लेकिन तब से यह अभी भी आदर्श नहीं है। समस्या विलय की घोषणा को बनाए रखने के लिए नामों को सिंक में रख रही है, लेकिन वास्तविक मूल्यों से संबंधित नहीं है।

nameof चाहने के और भी कई कारण हैं, लेकिन मुझे नहीं लगता कि यह DI के लिए उपयुक्त है।

@aluanhaddad

यह संभवतः वांछित प्रभाव नहीं होगा क्योंकि हर बार जब प्रतीक कहा जाता है तो यह एक नया अनूठा मूल्य बनाता है

आह हाँ, यह सच है। Symbol.for इसे ठीक कर देगा , लेकिन जैसा

इसका परिणाम @inject("Weapon") , जो छिपी हुई वैश्विक निर्भरता और टोकन टकराव का परिचय देगा।

हां, टोकन टकराव की संभावना है, लेकिन एक छोटी परियोजना पर जहां सभी इंटरफेस का एक अनूठा नाम होता है, यह पूरी तरह से ठीक काम करेगा (और InversifyJS इसे प्रबंधित करना वास्तव में आसान बनाता है, जैसा कि मैंने हाल ही में खोजा है)।

मैं देख सकता हूँ nameof निर्भरता इंजेक्शन के लिए एक अच्छा फिट होने के नाते _यदि आप सीमाओं से अवगत हैं_। ठीक उसी तरह, जैसा कि किसी ने इस धागे में पहले उल्लेख किया है, न्यूनतम कोड के साथ nameof का उपयोग करते समय सीमाएं होंगी। उदाहरण के लिए, आप पैरामीटर का नाम प्राप्त करने के लिए nameof का उपयोग कर सकते हैं। मिनिफिकेशन के दौरान, पैरामीटर का नाम बदल दिया जाता है, लेकिन कंपाइलर से उत्पन्न "मैजिक स्ट्रिंग" मूल नाम रखता है। हो सकता है कि आप मूल नाम चाहते हों, या हो सकता है कि आप संशोधित नाम चाहते हों। जब तक आप nameof साथ आने वाली सीमाओं से अवगत हैं, तब तक आप ठीक रहेंगे।

+1

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

function nameOf<T>(obj: T) {
  let name: string | undefined;

  const makeCopy = (obj: any): any => {
    const copy = {};
    for (const key in obj) {
      Object.defineProperty(copy, key, {
        get() {
          name = key;
          const value = obj[key];
          if (value && typeof value === "object") {
            return makeCopy(value);
          }
          return value;
        }
      });
    }
    return copy;
  };

  return (accessor: { (x: T): any }): string | undefined => {
    name = undefined;
    accessor(makeCopy(obj));
    return name;
  };
}

function pathOf<T>(obj: T) {
  let path: string[] = [];

  const makeCopy = (obj: any): any => {
    const copy = {};
    for (const key in obj) {
      Object.defineProperty(copy, key, {
        get() {
          path.push(key);
          const value = obj[key];
          if (value && typeof value === "object") {
            return makeCopy(value);
          }
          return value;
        }
      });
    }
    return copy;
  };

  return (accessor: { (x: T): any }): string[] => {
    path = [];
    accessor(makeCopy(obj));
    return path;
  };
}

उदाहरण उपयोग:

जब यह टाइप-लेवल पर होना चाहिए तो यह एक्सप्रेशन-लेवल ऑपरेटर क्यों है?

इस कदर:

type Meme = {}
type S = nameof Meme // NameOf<Meme> perhaps better?

const wrong: S = "wrong" // Type '"wrong"' is not assignable to type '"Meme"'.
const ok: S = "Meme"

@goodmind पृथ्वी पर आप "मेमे" (सैद्धांतिक रूप से एक स्ट्रिंग) का नाम एक प्रकार से क्यों निर्दिष्ट करना चाहेंगे? इसका कोई अर्थ नही बन रहा है। क्या आपका मतलब "typeof" से था?

const Why_does_TypeScript_not_have_this_yet: Explanation = { provided: false, reason: null };
console.log(`${nameof(Why_does_TypeScript_not_have_this_yet)}?`);
console.log(Why_does_TypeScript_not_have_this_yet);

if (!Why_does_TypeScript_not_have_this_yet.provided && (new Date()).getFullYear() >= 2018)
    this.me.sad = true;

मुझे अत्यधिक संदेह है कि वे इसे कभी भी लागू करेंगे क्योंकि nameof टाइप नेमस्पेस में नहीं है और किसी भी ईसीएमएस्क्रिप्ट प्रस्तावों में नहीं है।

हालांकि यह कोई समस्या नहीं है... यदि #14419 ("कस्टम ट्रांसफॉर्मर के लिए प्लगइन समर्थन") लागू किया गया तो हम nameof अपने स्वयं के कार्यान्वयन का उपयोग कर सकते हैं, जो एक मानक nameof से अधिक शक्तिशाली हो सकता है।

उदाहरण के लिए, यदि # 14419 को लागू किया गया है, तो हम परिवर्तन प्लगइन (उदाहरण के nameof कार्यान्वयन निर्दिष्ट करने के लिए सक्षम हो जाएगा यहाँ tsconfig.json में):

{
  "compilerOptions": {
    "customTransformers": {
      "before": ["node_modules/ts-nameof"]
    }
  }
}

तो कुल मिलाकर, मुझे लगता है कि इस मुद्दे की तुलना में # 14419 के लिए पूछना अधिक समझ में आता है क्योंकि यह नाम के लिए दरवाजा खोलता है और अन्य परिवर्तनों को आसानी से एक परियोजना में एकीकृत किया जाता है।

ईमानदारी से यह बेहतर होगा अगर यह सीधे "हमें यह नहीं चाहिए, क्षमा करें, क्षमा करें" के साथ बंद कर दिया गया था, फिर चुप्पी और ट्राइएज की कमी।

_ಠ

यहां एक रनटाइम संस्करण है जो मेरी आवश्यकताओं के लिए अच्छा काम करता है:

/** Returns the name of a namespace or variable reference at runtime. */
function nameof(selector: () => any, fullname = false) {
    var s = '' + selector;
    var m = s.match(/return\s+([A-Z$_.]+)/i)
        || s.match(/.*?(?:=>|function.*?{)\s*([A-Z$_.]+)/i);
    var name = m && m[1] || "";
    return fullname ? name : name.split('.').reverse()[0];
}

अगर नेमस्पेस एबीसी है और 'सी' स्कोप के अंदर है:
उपयोग: nameof(()=>A.B.C) // (रिटर्न "सी")
उपयोग: nameof(()=>A.B.C, true) // ("एबीसी" लौटाता है)

रिफैक्टरिंग के साथ-साथ बढ़िया काम करता है। जब स्क्रिप्ट पहली बार लोड होती है तो मैं केवल नेमस्पेस + क्लास पथ खींचने के लिए इसका उपयोग करता हूं, इसलिए यह कार्य के लिए कुशल से अधिक है।

+1
उस फीचर को जोड़ना बहुत मददगार होगा।
उदाहरण के लिए केस का प्रयोग करें:

ngOnChanges(changes: SimpleChanges) {
    let itemPropName: keyof MapComponent<T> = "items";
    if (changes[itemPropName])
      this.setItems();

    let centerCoordsPropName: keyof MapComponent<T> = "centerCoords";
    if (changes[centerCoordsPropName])
      this.goToCoordinates();
  }

@ इंजेक्शन योग्य ()
वर्ग निंजा {
कंस्ट्रक्टर(@इंजेक्ट (नाम (हथियार)) हथियार: हथियार) { }
}

ठीक वही जो मैं चाहता हूँ

@rayncc को यहां nameof का उपयोग करने की आवश्यकता नहीं है यदि आप एक ऐसे ढांचे का उपयोग करते हैं जो डेकोरेटर पर निर्भर करता है, जैसे कि टाइपस्क्रिप्ट IOC, कोणीय 2+, या @fluffy-spoon/inverse ।

@ffMathy

मैं असहमत हूं, nameof इंटरफेस इंजेक्शन के लिए विशेष रूप से उपयोगी होगा, जो केवल नाम में मौजूद है, लेकिन वास्तविक जेएस ऑब्जेक्ट के रूप में नहीं। यही कारण है कि आप @Inject(MyInterface) नहीं कर सकते, बल्कि इसके बजाय आपको @Inject('MyInterface') । यदि nameof कम से कम इंटरफेस के लिए उपलब्ध होता, तो हम @Inject(nameof MyInterface) , जो एक स्ट्रिंग (जो टाइपो के लिए प्रवण होता है) की तुलना में बहुत साफ होगा, और इससे भी महत्वपूर्ण बात यह है कि रिफैक्टर के साथ अच्छी तरह से काम करेगा।

С# में nameof क्यों न टाइपस्क्रिप्ट में एक जैसे फीचर जोड़े जाएं? यह बहुत मददगार होगा। अगर कोड मजबूती में सुधार होगा। यानी if (protoPropertyIsSet(msg, "expiration_utc_time")) बजाय हम लिख सकते हैं
if (protoPropertyIsSet(msg, nameof(msg.expiration_utc_time))) ।

@stasberkov C# उनके सिंटैक्स के पूर्ण नियंत्रण में है, टाइपस्क्रिप्ट को JS और भविष्य के किसी भी JS विकास के आसपास टिप-टो करना है। Enums को छोड़कर, टाइप एनोटेशन और टाइप एसेसर एक्सप्रेशन लेवल सिंटैक्स के प्रमुख एक्सटेंशन हैं। किसी भी नए अभिव्यक्ति स्तर के सिंटैक्स में JS से अलग होने और TS को JS के साथ किसी स्तर पर असंगत बनाने का खतरा होता है। यही कारण है कि nameof जोड़ना कोई आसान निर्णय नहीं है। इसे लागू करना मामूली है, लेकिन लंबी अवधि के निहितार्थ वापस काट सकते हैं।

@stasberkov C# उनके सिंटैक्स के पूर्ण नियंत्रण में है, टाइपस्क्रिप्ट को JS और भविष्य के किसी भी JS विकास के आसपास टिप-टो करना है। Enums को छोड़कर, टाइप एनोटेशन और टाइप एसेसर एक्सप्रेशन लेवल सिंटैक्स के प्रमुख एक्सटेंशन हैं। किसी भी नए अभिव्यक्ति स्तर के सिंटैक्स में JS से अलग होने और TS को JS के साथ किसी स्तर पर असंगत बनाने का खतरा होता है। यही कारण है कि nameof जोड़ना कोई आसान निर्णय नहीं है। इसे लागू करना मामूली है, लेकिन लंबी अवधि के निहितार्थ वापस काट सकते हैं।

अभिव्यक्ति nameof(XXX) को एक स्थिर स्ट्रिंग में संकलित किया जाएगा, जो मुझे लगता है कि JS के साथ पूरी तरह से संगत है

@rayncc उसका क्या मतलब था: क्या होगा यदि जेएस बाद में nameof ऑपरेटर में जोड़ता है जो टाइपस्क्रिप्ट के nameof ऑपरेटर से अलग व्यवहार करता है?

फिर एक संघर्ष होगा, जिसे किसी तरह सुलझाना होगा (और उसके लिए कोई आसान जवाब नहीं हैं)।

दूसरी ओर, nameof JS में आरक्षित शब्द नहीं है, इसलिए TC39 के इसे एक ऑपरेटर के रूप में जोड़ने की संभावना काफी कम है। इसलिए मुझे लगता है कि टाइपस्क्रिप्ट के लिए इसे जोड़ना काफी सुरक्षित है।

मुझे नहीं लगता कि यह मामला जेनेरिक या टाइपिंग से अलग है जिसे भविष्य में जावास्क्रिप्ट में एक अलग तरीके से लागू किया जा सकता है ... टाइपस्क्रिप्ट को उन अवधारणाओं को लागू करने के टीएस तरीके का समर्थन करते हुए इसका समर्थन करना चाहिए।

इसके लिए बहुत सारे उपयोग के मामले हैं, उदाहरण के लिए नेटिवस्क्रिप्ट की InformPropertyChange( nameof(property) ) विधि। BTW, उन्होंने पहले डेकोरेटर सामान के साथ ऐसा किया है। इसका समाधान यह था कि इसे 'प्रयोगात्मक' संकलक ध्वज के पीछे छिपा दिया जाए।

@markusmauch योग्य, देखो यह उनके लिए कैसे समाप्त हुआ

सज्जाकार अनुसरण करने के लिए अच्छा उदाहरण नहीं है

दूसरी ओर, JS में nameof एक आरक्षित शब्द नहीं है, इसलिए TC39 के इसे एक ऑपरेटर के रूप में जोड़ने की संभावना काफी कम है।

यूनरी उपसर्ग ऑपरेटरों को आरक्षित शब्द होने की आवश्यकता नहीं है क्योंकि op expr पहले से ही किसी भी op लिए एक अमान्य अभिव्यक्ति है जो ऑपरेटर नहीं है। उदाहरण के लिए, await पहले एक आरक्षित शब्द नहीं था, लेकिन इसे भाषा में जोड़ने में कोई समस्या नहीं थी क्योंकि यह केवल एक स्पष्ट यूनरी ऑपरेटर स्थिति में ही प्रकट होता है।

मैं यह भी कहना है हो सकता है ew करते keyof जो वास्तव में बहुत से अधिक शक्तिशाली है nameof , का परिणाम nameof सिर्फ एक है string , keyof हमें इनपुट को बेहतर तरीके से बाधित करने देता है।

जबकि nameof ऑपरेटर जितना सुंदर नहीं है, हम keyof का उपयोग फ़ंक्शन IMO का उपयोग करके कुछ ऐसा ही करने के लिए कर सकते हैं:

function nameof<T>(k: keyof T) : keyof T {
    return k
}
class Person {
    static defaultName: string;
    name!: string;
    studies!: {
        highSchool: string
        unversity: string
    }
}
let foo : { bar: { baz : { x: number }}}
let k1 = nameof<Person>("name")
let k2 = nameof<Person['studies']>("unversity")
let k3 = nameof<typeof Person>("defaultName")
let k4 = nameof<typeof foo['bar']['baz']>("x")

साधारण मामले के लिए यह सभ्य दिखता है, नेस्टेड पथों के लिए, यह थोड़ा भद्दा दिखता है, और आप इसे निजी तौर पर उपयोग नहीं कर सकते हैं।

@dragomirtitian भले ही {एक प्रकार के सुरक्षित दृष्टिकोण में नाम से सदस्यों तक पहुंच} समस्या (जो कमाल है) को पूरा करता है, जो संकलक को स्वचालित रूप से डेवलपर्स को रिफैक्टरिंग पर मदद नहीं करेगा, न ही यह आईडीई को किसी सदस्य के संदर्भों को देखने में मदद करेगा पाठ खोज किए बिना।

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

@dragomirtitian इस मुद्दे के भीतर ध्वस्त पदों के बारे में बात की गई है।

संक्षेप में, keyof आपके द्वारा उल्लिखित परिदृश्यों में मदद करता है, लेकिन फिर भी कुछ सामान्य उपयोग के मामले नहीं मिलते हैं जहां कक्षा या इंटरफ़ेस/प्रकार पहचानकर्ता नाम समन्वयित रहना अच्छा होगा।

भूतपूर्व। निर्भरता इंजेक्शन ढांचे ( @inject(nameof(Something)) ) का उपयोग करते समय, अच्छा तर्क त्रुटि संदेश फेंकना ...

function add(a: number, b: number) {
    throwArgumentErrorIfNaN(a, nameof(a));
    throwArgumentErrorIfNaN(b, nameof(b));

    return a + b;
}

..., परीक्षण विवरण नामों में...

import { CustomCollection } from "some-library";

describe(nameof(CustomCollection), () => {
    describe(nameof<CustomCollection>(c => c.add), () => {
    });
});

..., लॉग स्टेटमेंट लिखते समय ( logger.log(nameof(ClassName), LogLevel.Info, "Some log message.") ), और शायद अधिक।

nameof जोड़ने के कुछ लाभ हैं, लेकिन मेरी राय में इसे टाइपस्क्रिप्ट द्वारा नहीं किया जाना चाहिए क्योंकि यह सुझाव इस दिशानिर्देश को पूरा नहीं करता है:

• यह भावों के प्रकारों के आधार पर विभिन्न JS को उत्सर्जित किए बिना लागू किया जा सकता है।

संपादित करें: मेरा बुरा, इस गैर-लक्ष्य के बारे में सोच रहा था:

> * प्रोग्राम में रन-टाइम प्रकार की जानकारी जोड़ें या उस पर भरोसा करें, या टाइप सिस्टम के परिणामों के आधार पर अलग-अलग कोड उत्सर्जित करें। इसके बजाय, प्रोग्रामिंग पैटर्न को प्रोत्साहित करें जिन्हें रन-टाइम मेटाडेटा की आवश्यकता नहीं है।

साथ ही, मैं यह नहीं देखता कि TC39 को JS में जोड़ने के लिए क्या प्रेरणा होगी क्योंकि JS डेवलपर्स को इससे कोई लाभ नहीं होगा क्योंकि nameof(Identifier) लिखना JS में "Identifier" लिखने से थोड़ा ही बेहतर है गलत नाम वाले पहचानकर्ता का उपयोग करते समय संकलन समय त्रुटियों के कारण (मुझे लगता है कि रनटाइम वाले हो सकते हैं, लेकिन यह उतना अच्छा नहीं है)। साथ ही, TC39 में टाइप डोमेन में पहचानकर्ताओं के लिए nameof का समर्थन शामिल नहीं होगा (जैसे कि इंटरफ़ेस और टाइप उपनाम नाम)।

इसकी जगह शायद इसके लिए एक कंपाइलर प्लगइन (बेशर्म प्लग) होना है जिसे लोग अपनी परियोजनाओं में शामिल करना चुन सकते हैं।

के बारे में है कि क्या सुविधा के इस प्रकार दिशानिर्देश @dsherret मुझे आश्चर्य है अगर वहाँ एक और अधिक पुस्तकालय केंद्रित तरीका है कि linters द्वारा इस्तेमाल किया जा सकता stringly टाइप किया कोड है कि इरादा अधिक स्पष्ट रूप से कूटबद्ध लेने के लिए है ने उल्लेख के आधार पर TypeScirpt के लिए बिल्कुल उपयुक्त है के साथ एक चर या संपत्ति के नाम तक पहुँचने के लिए। मैंने ES6 टैग किए गए टेम्प्लेट लिटरल्स का उपयोग करके एक अवधारणा के साथ जल्दी से खेलने की कोशिश की, लेकिन दुर्भाग्य से ऐसा प्रतीत होता है कि कोई टेम्प्लेट पैरामीटर सिंटैक्स सहित मूल टेम्प्लेट स्ट्रिंग तक पहुंच सकता है, जो रनटाइम चेकिंग प्रदान करने के साथ-साथ सरल एक लाइनर की अनुमति देने का एक अच्छा तरीका होगा। चर के लिए मामले। मूल विचार सरल एक स्तर के गहरे गुणों के लिए उचित रूप से काम करता है और सिंटैक्स तर्कसंगत रूप से पारित पैरामीटर के साथ एक साधारण फ़ंक्शन कॉल से थोड़ा बेहतर है।

const props = {
  name : "Little John",
  slogan: "Rolls are rolls and tools are tools."
}

console.log(nameof`${props}.slogan`) // slogan
console.log(nameof`${props}.foo`) // ERROR: Property 'foo' not found on object 

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

nameof जोड़ने से निश्चित रूप से कुछ लाभ है, लेकिन मेरी राय में इसे टाइपस्क्रिप्ट द्वारा नहीं किया जाना चाहिए क्योंकि यह सुझाव इस दिशानिर्देश को पूरा नहीं करता है:

• यह भावों के प्रकारों के आधार पर विभिन्न JS को उत्सर्जित किए बिना लागू किया जा सकता है।

क्या आप स्पष्ट कर सकते हैं कि इस संदर्भ में विभिन्न JS का क्या अर्थ है? उदाहरण के लिए, यदि nameof<InterfaceA> और nameof<InterfaceB> दोनों एक स्ट्रिंग को आउटपुट करते हैं जिसमें अलग-अलग मान होते हैं लेकिन एक ही प्रकार साझा करते हैं, तो क्या इसे अलग माना जाता है?

@JLWalsh मुझे लगता है कि मैंने गलत तरीके से पढ़ा होगा कि अभिव्यक्तियों के प्रकार के आधार पर अलग-अलग जेएस उत्सर्जित नहीं करना (जब मैंने इसे कॉपी और पेस्ट किया तो मैं स्मृति से आधा जा रहा था)। तो एक कॉल अभिव्यक्ति लेना और एक स्ट्रिंग अक्षर उत्सर्जित करना। मुझे अब यकीन नहीं है कि उस बिंदु का अब क्या मतलब है, लेकिन आज बहुत लंबे समय तक प्रोग्रामिंग के बाद मेरा दिमाग तला हुआ है।

मैं इस गैर-लक्ष्य के बारे में सोच रहा था:

• प्रोग्राम में रन-टाइम प्रकार की जानकारी जोड़ें या उस पर भरोसा करें, या टाइप सिस्टम के परिणामों के आधार पर अलग-अलग कोड उत्सर्जित करें। इसके बजाय, प्रोग्रामिंग पैटर्न को प्रोत्साहित करें जिन्हें रन-टाइम मेटाडेटा की आवश्यकता नहीं है।

कृपया इसे जोड़ें

@rjamesnw
अभिव्यक्ति में संख्याओं के मामले में, मैंने कुछ संशोधन किया है:

function nameof(selector: () => any, fullname = false) {
    var s = '' + selector;
    var m = s.match(/return\s+([A-Z0-9$_.]+)/i)
        || s.match(/.*?(?:=>|function.*?{)\s*([A-Z0-9$_.]+)/i);
    var name = m && m[1] || "";
    return fullname ? name : name.split('.').reverse()[0];
}

टीसी39 थ्रेड्स को नीति के रूप में लॉक करना क्योंकि टीसी39 ने अभी तक ऐसा नहीं किया है, इसके बारे में शिकायत करने के अलावा वास्तव में बात करने के लिए कुछ भी नहीं है