Typescript: सज्जाकार

मुझे जो युक्ति समझ में आती है, उसके लिए क्षमा करें, हम ऐसा नहीं कर पाएंगे:

<strong i="6">@F</strong>
function test() {
}

क्या मैं सही हूँ ?

टाइप क्रमांकन बाकी तर्कों के साथ कैसे काम करता है?

@F()  
class Foo {  
    constructor(...args: string[]) {  
    }  
}  

function F(<strong i="6">@paramterTypes</strong> types?: Function[]) {  
    return function (target) {  
        target.paramterTypes = types; // ???  
    }  
}

सज्जाकारों का उपयोग करना काफी सरल लगता है, लेकिन मैंने उन्हें भ्रामक घोषित करने के बारे में अनुभाग पाया। C.4 का कहना है कि सज्जाकारों को @decorator साथ एनोटेट करने की आवश्यकता है, लेकिन उदाहरणों में से एक भी वास्तव में ऐसा नहीं दिखाता है।

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

CoverMemberExpressionSquareBracketsAndComputedPropertyName की व्याख्या को परिष्कृत करने का नियम क्या है?

मैंने देखा कि कई टाइपिंग में विभिन्न बिंदुओं पर Function | Object , लेकिन ये टाइप चेक टाइम पर ऑब्जेक्ट में खराब हो जाएंगे। वहां फंक्शन होने का क्या कारण है?

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

सजाए गए निर्यात के लिए, [lookahead ≠ @] किसके लिए है? क्या HoistableDeclaration और ClassDeclaration वास्तव में @ ?

यह #1557 . का ढोंग है

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

मेरी गलती।

फंक्शन एक्सप्रेशन पर डेकोरेटर के लिए, क्या हम ऐसा कुछ नहीं कर सकते:

@F("color") <strong i="6">@G</strong> 
function myFunc() {
   doSomething();
}

में तब्दील:

var _t = function() {
   doSomething();
}
_t = F("color")(_t = G(_t) || _t) || _t;  

function myFunc() {
  return _t.apply(this, arguments)
}

हर फंक्शन को सही करना कुछ लोगों को परेशान करता है जैसे:

const myFunc = function () {}

आपने उत्थापन ढीला कर दिया, और function.name

पीआर #2399 . में कार्यान्वयन जोड़ा गया

अपडेट: प्रस्ताव अपडेट किया गया, और @wycats ES7 जावास्क्रिप्ट डेकोरेटर्स के लिए लिंक जोड़ा गया।

दुख की बात है कि यह केवल एक वर्ग बन गया ...
इसके अलावा एंबियंट डेकोरेटर के बारे में क्या वे दायरे से बाहर हो गए?

कार्यों के लिए आपके प्रस्ताव के साथ @fdecampredon , ऐसा लगता है कि आप अभी भी उत्थापन खो रहे हैं।

@JsonFreeman क्यों? यदि आप फ़ाइल के शीर्ष पर _t डालते हैं?

import something from 'something';

myFunc(something.something());

@F("color") <strong i="8">@G</strong> 
function myFunc() {
  doSomething()
}

import something from 'something';

var _t = function() {
   doSomething();
}
_t = F("color")(_t = G(_t) || _t) || _t;  

myFunc(something.something());

function myFunc() {
  return _t.apply(this, arguments)
}

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

@fdecampredon यह सामान्य मामले के लिए काम नहीं करता है, क्योंकि सज्जाकार स्वयं अभिव्यक्ति हैं। जैसे

myFunc();  // assumes function declaration is hoisted

var dec = (t) => t; // defininig a decorator

<strong i="7">@dec</strong>
function myFunc() {}

यदि आप डेकोरेटर के फंक्शन डिक्लेरेशन और एप्लिकेशन को फहराते हैं तो आप डेकोरेटर को तोड़ देते हैं। यदि आप केवल फंक्शन डिक्लेरेशन को फहराते हैं, लेकिन डेकोरेटर एप्लिकेशन को नहीं, तो आप फंक्शन को एक अघोषित अवस्था में देख सकते हैं। यहां कोई आकर्षक समाधान नहीं है।

यह वही मुद्दा है जो वर्ग घोषणा के साथ खंड का विस्तार करता है, जो ES6 में एक अभिव्यक्ति है। परिणाम वर्ग घोषणा नहीं फहरा रहा था, केवल प्रतीक (var घोषणा के समान, लेकिन कार्य घोषणा नहीं)

ओह्स ने इसके बारे में नहीं सोचा @mhegazy धन्यवाद।
हालाँकि, फ़ंक्शन भाग ने मूल @jonathandturner प्रस्ताव को पूरी तरह से क्यों छोड़ दिया था, इसका नियम था:

decorated function declarations cannot be hoisted to the containing scope

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

आइए देखें कि बाधाओं के वांछित सेट का क्या अर्थ है:

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

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

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

ऐसा कहने के बाद, ES7 प्रस्ताव अभी भी अपने प्रारंभिक चरण में है, इसलिए मुझे उम्मीद है कि यह विकसित और विस्तारित होगा; इसलिए यह कल्पना की जा सकती है कि अंतिम प्रस्ताव में किसी न किसी रूप में कार्य शामिल होंगे।

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

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

<strong i="7">@dec1</strong>
function dec2(target: Function) {
   // Do stuff
}

<strong i="8">@dec2</strong>
function dec1(target: Function) {
   // Do stuff
}

भले ही दोनों समारोह फहराए जाएं, फिर भी कौन सा पहले सजाया जाता है? यदि dec2 को पहले सजाया जाता है, तो dec1 को उस समय तक नहीं सजाया जाएगा जब तक कि इसे dec2 पर लागू नहीं किया जाता है।

तो हमें निम्नलिखित के बीच चयन करना होगा:

• कार्यों को फहराया नहीं जाता है
• अलंकृत कार्यों को फहराया जाता है, लेकिन डेकोरेटर अनुप्रयोग उनके साथ नहीं फहराए जाते हैं।

जबकि मुझे इनमें से कोई भी पसंद नहीं है, मुझे नहीं लगता कि और कुछ भी संभव है।

यह जेएस का प्रस्ताव है। इसलिए इंजन को पता नहीं चलेगा कि अभिव्यक्ति फ़ंक्शन घोषणा को संदर्भित करती है या नहीं, स्थिर विश्लेषण के साथ हम हालांकि बता सकते हैं। इस पर विचार करो:

<strong i="6">@dec1</strong>
function dec2(target: Function) {
   // Do stuff
}

dec2 = undefined;

<strong i="7">@dec2</strong>
function dec1(target: Function) {
   // Do stuff
}

उह! जावास्क्रिप्ट अब और आसान नहीं हो रहा है। :-)

इसे केवल फ़ंक्शन _expressions_ पर सक्षम करना आसान होगा:

const foo = <strong i="6">@decorator</strong> () => {
    // ...   
}
const bar = <strong i="7">@decorator</strong> function() {
    // ...
}

फंक्शन एक्सप्रेशन या लैम्ब्डा फहराया नहीं जाता है।

क्या टाइपस्क्रिप्ट 1.5.0-अल्फा में डेकोरेटर में इस तरह के पैरामीटर होना संभव है?

@dec1({key1: value1, key2, value2})
function dec2(target: Function) {
   // Do stuff
}

ठीक है, कोई बात नहीं, बस एक कारखाना बनाएं जो पैरामीटर लेता है और वास्तविक डेकोरेटर फ़ंक्शन लौटाता है।

उदाहरण के लिए, एक स्ट्रिंग पैरामीटर वाला क्लास डेकोरेटर:

function decoratorWithString(param: string) { // Decorator factory
    return function(target) { // Actual decorator
        // Do stuff with target and string parameter
    }
}

// Usage
@decoratorWithString('foobar')
class Foo {

}

अभिवादन।

मैं यह पता लगाने की कोशिश कर रहा हूं कि एक डेकोरेटर कैसे लिखना है जो कंस्ट्रक्टर में घोषित प्रकारों को उठाएगा।

यहां कुछ कोड है जो दिखाता है कि मैं क्या करने की कोशिश कर रहा हूं, लेकिन यह कड़ी मेहनत है। मुझे कक्षा डी में कन्स्ट्रक्टर घोषणा का जवाब देने के लिए इसकी आवश्यकता है

class A {
  public message = "identity: class A";
}

class B {
  public message = "identity: class B";
}

<strong i="8">@decoTest</strong>
class D {
  static metadata:Array<Function> = [];
  constructor(a: A, b: B) {
  }
}
describe("decorators", function() {
  it("should inject constructor types", function() {
    var d = new D(new A(), new B());
    expect(D.metadata.length).toBe(2);
  });
});


function decoTest<T>(target: T, ...rest) {
  target["metadata"].push(A, B); // how do i get this based on constructor ???
  return target;
}

मुझे डर है कि प्रकार की जानकारी डेकोरेटर सुविधा के दायरे से बाहर है।
आप उस तरह की जानकारी जोड़ने के लिए प्रत्येक पैरामीटर पर ParameterDecorator का उपयोग कर सकते हैं।

ParameterDecorator के लिए टाइपिंग या कार्यान्वयन बिल्कुल सही नहीं है, टाइपिंग से लक्ष्य एक फ़ंक्शन है, लेकिन टाइपस्क्रिप्ट का उपयोग करते समय, यह प्रोटोटाइप ऑब्जेक्ट है।
सही प्रकार प्राप्त करने के लिए मुझे लक्ष्य पैरामीटर डालना होगा:

function MyParameterDecorator (_target: Function, methodName: string, index: number) {
    const target = <InterfaceForMyUseCase><anyt>_target;
    // do stuff
}

के बजाए:

function MyParameterDecorator (target: InterfaceForMyUseCase, methodName: string, index: number) {
    // do stuff
}

वाह - पैरामीटर सज्जाकार नियम !!!!!!!!!!!!!!! यह रेपो देखें

परीक्षण चलाने से आउटपुट यहां दिया गया है:

LOG: 'injectMe:'
LOG: '  type: class A'
LOG: '  type: class B'
LOG: '  some key'

और कोड :

module ParameterDecorators {
  class A {
    static typeName:string = "type: class A";
    public instanceTypeName = "instance: class A";
  }

  class B {
    static typeName:string = "type: class B";
    public instanceTypeName = "instance: class B";
  }

  @injectTest(A, B, "some key")
  class C {
    static injectMe: Array<any> = [];
    constructor(a: A, b: B) {
    }
  }

  function injectTest(...rest) {
    return function(target): void {
      target["injectMe"] = rest;
    }
  }

  describe("decorators", function() {
    it("should inject dependency-injection keys", function() {
      var c = new C(new A(), new B());
      console.log("injectMe:");
      for (let parm of C.injectMe) {
        if (typeof(parm) === "function") {
          console.log("\t" + parm["typeName"]);
        } else {
          console.log("\t" + parm)
        }
      }
    });
  });
}

मैंने एक्सप्रेस के चारों ओर एक रैपर बनाया है (लेकिन किसी भी वेब ढांचे का समर्थन किया जा सकता है, एक एडेप्टर इंटरफ़ेस परिभाषित किया गया है) एक डेकोरेटर आधारित एपीआई के साथ: https://github.com/cybrown/web-decorators

मैं ClassDecorator, ParameterDecorator और MethodDecorator का उपयोग कर रहा हूं।

@cybrown मैंने अभी #2635 में ParameterDecorator लिए हस्ताक्षर अपडेट किया है, जो अब मास्टर में है।

@rbuckton धन्यवाद, मैं कल इसे अपने प्रोजेक्ट में अपडेट कर दूंगा।

क्या पैरामीटर डेकोरेटर में पैरामीटर का नाम होना संभव है?
यह उपयोगी हो सकता है क्योंकि मुझे लगता है कि पैरामीटर का नाम पैरामीटर डेकोरेटर के पहले तर्क का आधा समय हो सकता है।
इसके अलावा, यह मिनीफायर द्वारा पैरामीटर नाम मैंगलिंग का समाधान हो सकता है।

मुझे इसे पूरा करने के लिए कहा गया है:

@inject(A, B, "some key")
  class C {
    static injectMe: Array<any> = [];
    constructor(a: A, b: B) {
    }
  }

  function inject(...rest) {
    return function(target): void {
      target["inject"] = rest;
    }
  }

लेकिन इंजेक्ट डेकोरेटर में कुंजियों को निर्दिष्ट किए बिना, लेकिन इसके बजाय सज्जाकार इन पंक्तियों के साथ कुछ के साथ कंस्ट्रक्टर के वर्ग कार्यों को स्वचालित रूप से उठाते हैं:

inject(<strong i="9">@parameterTypes</strong> types:Function[]){ ... }

मैं देख रहा हूँ कि कैसे करना है @jonathandturner यहाँ वर्णन करता

@cmichaelgraham हां रनटाइम प्रकार की जानकारी (आरटीटीआई जैसा कि एटस्क्रिप्ट में वर्णित है) उस तरह के उपयोग के लिए बहुत बढ़िया होगा, यहां तक ​​​​कि आत्मनिरीक्षण जैसी पूरी तरह से अलग सुविधा में भी।

@cmichaelgraham https://github.com/Microsoft/TypeScript/pull/2589 पर

@cmichaelgraham हम ES7 के लिए एक मेटाडेटा API जोड़ने के प्रस्ताव पर काम कर रहे हैं जो सज्जाकारों के साथ मिलकर काम करेगा। #2589 उस प्रस्ताव के लिए प्रयोगात्मक समर्थन जोड़ता है, लेकिन मेटाडेटा को पढ़ने के लिए एक अलग पॉलीफ़िल की आवश्यकता होती है।

@rbuckton @cmichaelgraham मूल रूप से विशेष टाइपस्क्रिप्ट डेकोरेटर के लिए एक डिज़ाइन था जो संकलक को डेकोरेटर में टाइप करने के लिए कहता है, जो लक्ष्य को सजाया जा रहा है। मुझे लगता है कि यह @parameterTypes क्या मैं यह सोचने में सही हूं कि उस सुविधा को अधिक सामान्य मेटाडेटा एपीआई के पक्ष में हटाया जा रहा है? अगर ऐसा है तो मैं इसका समर्थन करूंगा।

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

@EisenbergEffect डेकोरेटर 1.5 का हिस्सा हैं, आप इसे हमारी नवीनतम रिलीज़ 1.5-alpha के साथ उपयोग करना शुरू कर सकते हैं।

मेटा डेटा सपोर्ट के लिए। @paramtypes के ओरिजिनल प्रस्ताव के बाद से डिजाइन बदल गया है। नया desing प्रतिबिंब.मेटाडा प्रस्ताव का उपयोग कर रहा है। यह कैसे काम करता है, इसके बारे में अधिक जानकारी के लिए #2589 देखें। साथ ही @rbuckton में मेटाडेटा का उपभोग करने के लिए एक पॉलीफ़िल है: https://github.com/rbuckton/reflectDecorators

@mhegazy मुझे पता है। यहां देखें: http://blog.durandal.io/2015/04/09/aurelia-update-with-decorators-ie9-and-more/ :smile:

मैं मेटाडेटा प्रस्ताव से भी परिचित हूं। मैं उस पर फीडबैक देता रहा हूं। मैं सिर्फ यह जानना चाहता था कि मूल @parameterTypes विचार को हटाया जा रहा है या नहीं।

धन्यवाद @EisenbergEffect साझा करने के लिए। :+1:

हां। @paramtypes साथ एकमात्र मुद्दा यह है कि यह प्रकार प्रणाली द्वारा निर्देशित उत्सर्जन करता है, और वैश्विक कार्यक्रम की जानकारी की आवश्यकता होती है। यह सिंगल-मॉड्यूल ट्रांसपिलेशन के लिए परिदृश्यों को तोड़ता है (देखें #2499)। दूसरा विकल्प इसे कॉल साइटों पर रखना था, जो लेखकों के बजाय डेकोरेटर उपयोगकर्ताओं पर बहुत अधिक काम जोड़ता है। इसलिए हम वापस ड्राइंग बोर्ड पर गए और इसके बजाय रिफ्लेक्ट.मेटाडेटा दृष्टिकोण पर उतरे।

यदि आपने प्रस्ताव के पुराने संस्करणों को भी देखा, तो हमें उसी कारण से परिवेश/डिज़ाइन-टाइम डेकोरेटर्स को हटाना पड़ा।

स्पष्टीकरण देने के लिए धन्यवाद। यह सब समझ में आता है। कोई विचार अगर प्रतिबिंब-आधारित दृष्टिकोण 1.5 में उतरेगा?

हां। यह वर्तमान में मास्टर में है। यह अगली रिलीज में उपलब्ध होना चाहिए। यह वर्तमान में प्रयोगात्मक ध्वज --emitDecoratorMetadata का उपयोग करने वाली एक ऑप्ट-इन सुविधा है; और यह केवल सजाए गए निकायों में मेटाडेटा जोड़ता है।

"यह केवल सजाए गए इकाइयों में मेटाडेटा जोड़ता है" क्या आप उस विचार पर विस्तार कर सकते हैं? क्या एक विशेष डेकोरेटर शामिल है? या क्या यह इसे किसी डेकोरेटर के साथ किसी भी चीज़ में जोड़ता है? दूसरे शब्दों में, यदि कोई डेवलपर ऑरेलिया के inject डेकोरेटर का उपयोग करता है, तो क्या वह मेटाडेटा उत्पन्न करने के लिए कंपाइलर को ट्रिगर करेगा?

यदि कोई डेवलपर ऑरेलिया के इंजेक्ट डेकोरेटर का उपयोग करता है, तो क्या वह संकलक को मेटाडेटा उत्पन्न करने के लिए ट्रिगर करेगा?

हां।

मेरा मतलब था:

<strong i="9">@inject</strong>
class Foo {
    constructor(a: number, b: string) {}
}

class Bar {
    constructor(a: number, b: string) {}
}

--emitDecoratorMetadata के साथ कंपाइलर Foo लेकिन _not_ Bar लिए टाइप मेटाडेटा (यानी reflect.metadata('desing:paramtypes', [Number, String]) कॉल करें) उत्सर्जित करेगा।

वही हमारे काम आएगा। हम अपनी अगली रिलीज के लिए रिफ्लेक्ट.मेटाडेटा एपीआई के लिए समर्थन तैयार करेंगे, संभवत: अगले सप्ताह। स्पष्टीकरण के लिए धन्यवाद!

तो इसके लिए क्या उत्सर्जित किया जाता है?

``` भाषा = जावास्क्रिप्ट
@इंजेक्ट
कक्षा फू {
कंस्ट्रक्टर (ए: ए, बी: बी) {}
}

कक्षा बार {
कंस्ट्रक्टर (ए: नंबर, बी: बी) {}
}

would it be (for Foo):

``` javascript
reflect.metadata('desing:paramtypes', [A, B])

@cmichaelgraham हां, यह मोटे तौर पर उत्पन्न होता है।

सनकी मस्त !!!!

इस रेपो को बनाने के लिए गल्प-टाइपस्क्रिप्ट का उपयोग करना - (अच्छा काम @ivogabe)

gulpfile build-ts कमांड ( emitDecoratorMetadata विकल्प पर ध्यान दें):

gulp.task('build-ts', function () {
    var tsResult = gulp.src([
        './views/*.ts',
        './typings/**/*.d.ts',
        './*.ts'
        ],
        {base: "."})
    .pipe(ts({
         typescript: require('typescript'),
         declarationFiles: false,
         noExternalResolve: true,
         target: "es5",
         module: "amd",
         emitDecoratorMetadata: true
    }));

    return merge([
        tsResult.dts.pipe(gulp.dest('.')),
        tsResult.js.pipe(gulp.dest('.'))
    ]);
});

app.ts बदल जाता है

import {inject} from 'aurelia-framework';
import {Router} from 'aurelia-router';
import 'bootstrap';
import 'bootstrap/css/bootstrap.css!';

@inject(Router)
export class App {
  public router;
  constructor(router:Router) {
    this.router = router;
    this.router.configure(config => {
      config.title = 'Aurelia';
      config.map([
        { route: ['','welcome'],  moduleId: './welcome',      nav: true, title:'Welcome' },
        { route: 'flickr',        moduleId: './flickr',       nav: true },
        { route: 'child-router',  moduleId: './child-router', nav: true, title:'Child Router' }
      ]);
    });
  }
}

app.js

var __decorate = this.__decorate || (typeof Reflect === "object" && Reflect.decorate) || function (decorators, target, key, desc) {
    switch (arguments.length) {
        case 2: return decorators.reduceRight(function(o, d) { return (d && d(o)) || o; }, target);
        case 3: return decorators.reduceRight(function(o, d) { return (d && d(target, key)), void 0; }, void 0);
        case 4: return decorators.reduceRight(function(o, d) { return (d && d(target, key, o)) || o; }, desc);
    }
};
var __metadata = this.__metadata || (typeof Reflect === "object" && Reflect.metadata) || function () { };
define(["require", "exports", 'aurelia-framework', 'aurelia-router', 'bootstrap', 'bootstrap/css/bootstrap.css!'], function (require, exports, aurelia_framework_1, aurelia_router_1, , ) {
    var App = (function () {
        function App(router) {
            this.router = router;
            this.router.configure(function (config) {
                config.title = 'Aurelia';
                config.map([
                    { route: ['', 'welcome'], moduleId: './welcome', nav: true, title: 'Welcome' },
                    { route: 'flickr', moduleId: './flickr', nav: true },
                    { route: 'child-router', moduleId: './child-router', nav: true, title: 'Child Router' }
                ]);
            });
        }
        App = __decorate([
            aurelia_framework_1.inject(aurelia_router_1.Router), 
            __metadata('design:paramtypes', [aurelia_router_1.Router])
        ], App);
        return App;
    })();
    exports.App = App;
});

विशेष रुचि कंस्ट्रक्टर मापदंडों के बारे में उत्सर्जित प्रकार मेटाडेटा है:

        App = __decorate([
            aurelia_framework_1.inject(aurelia_router_1.Router), 
            __metadata('design:paramtypes', [aurelia_router_1.Router])
        ], App);

इसलिए सिद्धांत रूप में, आप इंजेक्शन में निर्दिष्ट किए बिना उचित कक्षाओं को इंजेक्ट करने के लिए इंजेक्ट डेकोरेटर फ़ंक्शन को बदल सकते हैं, लेकिन इसके बजाय कंस्ट्रक्टर में प्रकार निर्दिष्ट कर सकते हैं :)

@cmichaelgraham हम आज ढांचे में बदलाव किए बिना इसे आसानी से सक्षम कर सकते हैं। ऑरेलिया की DI लाइब्रेरी में एक हुक container.addParameterInfoLocator । आप इसे एक ऐसा फ़ंक्शन पास करते हैं जो एक प्रकार ले सकता है और इसकी निर्भरता वापस कर सकता है। हमारी अगली रिलीज़ (अगले सप्ताह) के लिए, हम इसे कोर कॉन्फ़िगरेशन में जोड़ सकते हैं, हालांकि टाइपस्क्रिप्ट डेवलपर्स के लिए इसे चालू करना आसान है। मैं इसे इस सप्ताह की रिलीज़ में डाल देता, लेकिन मुझे यह नहीं पता था कि यह अभी तक बदला गया है।

@EisenbergEffect शानदार !! :+1:

मैंने किसी वस्तु के गुणों को देखने योग्य के रूप में चिह्नित करने के लिए एनोटेशन का उपयोग किया, जो एक आदिम को एक अवलोकन योग्य वस्तु में बदल देता है (रुचि रखने वालों के लिए, https://github.com/mweststrate/MOBservable/commit/8cc7fc0e20c000db660037c8b5c9d944fe4155d9)।

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

इसके अलावा, कमाल की सुविधा!

मेटाडेटा प्रतिबिंब एपीआई का उपयोग करके मैं एक साधारण गुण निर्भरता इंजेक्शन करने में सक्षम था।
आप यहां आवश्यक परिवर्तनों की जांच कर सकते हैं https://github.com/matjaz/property-DI/commit/2b4835e100b72d954b57d0e656ea524539ac17eb।

जेनरेट कोड में __मेटाडेटा डेकोरेटर नहीं होना चाहिए जो सभी डेकोरेटर्स में सबसे पहले लागू होता है? मैं कक्षा के मेटाडेटा का उपयोग करके सरल डिओक्रेटर बनाना चाहता था, लेकिन __metadata('design:paramtypes', [TYPES...]) को अंतिम रूप से लागू किया जाता है, इसलिए मैं इन डेटा को रिफ्लेक्ट से प्राप्त नहीं कर सकता

@ufon क्या आप वह कोड साझा कर सकते हैं जिसे आप देख रहे हैं?

ज़रूर, यहाँ https://gist.github.com/ufon/5a2fa2481ac412117532

संपादित करें:
मेरा बुरा, मेरे कोड में कुछ और गलती है, क्लास इनिशियलाइज़ेशन के बाद भी टाइप नहीं मिल सकता है

@ufon , मुझे यकीन नहीं है कि मैं इस मुद्दे को तब देखता हूं। __मेटाडेटा डेकोरेटर सूची में अंतिम आइटम है, इसका मतलब है कि यह निष्पादित करने वाला पहला है, और निश्चित रूप से इंजेक्शन को निष्पादित करने से पहले।

    House = __decorate([
        inject_1.inject, 
        __metadata('design:paramtypes', [Floor, String])
    ], House);

जहां __decorate परिभाषा डेकोरेटर्स को उल्टे क्रम में निष्पादित करने के अधिकार को कम करती है।

decorators.reduceRight(function(o, d) { return (d && d(o)) || o; }, target);

यह कल्पना से मेल खाने के लिए है, कि डेकोरेटर (अभिव्यक्ति के रूप में) का मूल्यांकन घोषणा के क्रम में किया जाता है, लेकिन रिवर्स ऑर्डर में निष्पादित किया जाता है, जिससे बाहरी सज्जाकार आंतरिक सज्जाकारों से परिणामों का उपभोग कर सकते हैं।

मैं देखता हूं, नाराज होने के लिए खेद है :) मेरा बुरा, मेरे कोड में कुछ और गलती है, क्लास इनिशियलाइज़ेशन के बाद भी टाइप नहीं मिल सकता है

आप उनके लिए कैसे पूछताछ कर रहे हैं? और क्या आपके पास रिफ्लेक्ट.मेटाडेटा के लिए पोलीफिल है?

सार में जोड़ा गया ...
प्रतिबिंब.getMetadataKeys (हाउस);
यह खाली सरणी का परिणाम है ..

हां, मुझे 'प्रतिबिंब-मेटाडेटा' पैकेज की आवश्यकता है

ऐसा लगता है कि पॉलीफिल इसे खो रहा है, डाल सकते हैं।

सोचो मुझे मिल गया ...
आवश्यकताएँ टाइपप्रति के सहायक कोड के बाद स्थानांतरित की जाती हैं

var __metadata = this.__metadata || (typeof Reflect === "object" && Reflect.metadata) || function () { };
require('reflect-metadata');

इसलिए, समय में var __metadata को आरंभिक किया जा रहा है, पॉलीफ़िल अभी तक लोड नहीं हुआ है

लेकिन मुझे जेनरेट कोड से पहले ये आवश्यकता नहीं मिल सकती है

संपादित करें: जिस्ट को अपडेट किया गया .. जब एकल मॉड्यूल संकलित किया जाता है, तो __मेटाडेटा हल होने से पहले पॉलीफिल लोड करने का कोई तरीका नहीं है, क्योंकि टाइपस्क्रिप्ट का जेनरेट कोड हमेशा फ़ाइल के शीर्ष पर ले जाया जाता है

ओह .. यह एक बड़ा मुद्दा है। इसे ट्रैक करने के लिए लॉग किया गया मुद्दा #2811

तब तक आपको दूसरे मॉड्यूल में reflect-metadata की आवश्यकता है (आपको दो फाइलों की आवश्यकता है)।
देखें https://github.com/matjaz/property-DI/

एक आमंत्रण असंगतता प्रतीत होती है जो विकासशील सजावटी को परिवर्तनीय/वैकल्पिक पैरामीटर के साथ करना बहुत मुश्किल बनाती है। उदाहरण के तौर पे:

<strong i="6">@F</strong>
prop: number;

@F()
prop: number;

पूर्व में, F को मापदंडों (लक्ष्य, संपत्ति का नाम, संपत्ति डिस्क्रिप्टर) के साथ लागू किया जाता है, जबकि बाद में, F को मापदंडों () के साथ लागू किया जाता है और इसके लिए आपको एक आंतरिक फ़ंक्शन की आवश्यकता होती है जो बदले में (लक्ष्य, संपत्तिनाम और) के साथ लागू हो जाता है। प्रॉपर्टी डिस्क्रिप्टर)।

मेरा _assumption_ यह होता कि @F और @F() दोनों समान होंगे और इसलिए आप केवल कॉल कर सकते हैं यदि डेकोरेटर 0 या अधिक मापदंडों का समर्थन करता है।

यह इस मामले में विशेष रूप से महत्वपूर्ण है:

<strong i="13">@F</strong>  // Performs some default behaviour.
prop: number;

@F({ option: true }) // Performs some configured behaviour.
prop: number;

यह सिर्फ स्पष्ट रूप @F के बजाय @F () कॉल करके चारों ओर काम किया जा सकता है, लेकिन यह है कि गलती करते हैं और उसके बाद आसान है भ्रमित हो जब अपने डेकोरेटर इसके बारे में यह होना चाहिए दिखता द्वारा भले ही काम नहीं करता।

इस मामले में मैं निम्नलिखित करना चाहूंगा:

export function F(options?: any): PropertyDecorator {
    return (target, name) => {
        // do something.
    }
}

और इसके साथ किया जाना चाहिए, लेकिन इसके बजाय मुझे निम्नलिखित कच्चे उदाहरण की तरह कुछ करना है:

export function F(...args: any[]): any {
   var func = (target, name) => {
      // do something.
   }

   if (args.length === 1) return func;
   else if (args.length === 2) func(args[0], args[1]);
}

जो एक वास्तविक दर्द है।

@ थारैक्सिस यह व्यवहार डिजाइन द्वारा है। @F और @F() बराबर नहीं हैं। @F एक डेकोरेटर को कॉल करता है F , जहां @F() एक डेकोरेटर फैक्टर को कॉल करता है F खाली तर्क सूची के साथ, और फिर परिणामी डेकोरेटर लागू करता है।

यहां समस्या यह है कि कंपाइलर डेकोरेटर फैक्ट्री F के हस्ताक्षर की तुलना declare type PropertyDecorator = (target: Object, propertyKey: string | symbol) => void; जो कि असाइन करने योग्य होता है। मुझे लगता है कि हमें यह सुनिश्चित करने के लिए यहां एक मजबूत जांच की आवश्यकता है कि हम इन मुद्दों को पकड़ लें। मैंने इसे ठीक करने के लिए #3246 लॉग किया है। मेरा मानना ​​​​है कि आप सही काम कर रहे हैं, और कंपाइलर को डेकोरेटर फैक्ट्री के अमान्य उपयोगों को पकड़ना चाहिए।

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

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

कंपाइलर के पास यह जानने का कोई तरीका नहीं है कि यह फैक्ट्री है या डेकोरेटर। यदि आपके पास यह हस्ताक्षर है:

declare function decoratorOrFactory (...args: any[]): any;

यह डेकोरेटर है या फैक्ट्री है, इसे खाली तर्कों के साथ बुलाया जाना चाहिए या नहीं?

सबसे अधिक संकलक यह सत्यापित कर सकता है कि हस्ताक्षर एक या दूसरे तरीके से कॉल करते समय मेल खाता है, और यदि ऐसा नहीं होता है तो त्रुटियां दें।

@rbuckton में #3246 के लिए एक फिक्स है जो उन मामलों को चिह्नित करना चाहिए जहां आपके डेकोरेटर का उपयोग कारखाने के रूप में नहीं किया जाता है, इसलिए बने रहें।

@mhegazy , मैं जो कह रहा हूं वह यह है कि एक डेकोरेटर (यानी @F या @F() ) का उपयोग _always_ फ़ैक्टरी फ़ंक्शन F का आह्वान होना चाहिए, जो बदले में उपयुक्त डेकोरेटर प्रकार लौटाता है। एक एनकैप्सुलेटिंग फैक्ट्री के बिना डेकोरेटर का कोई शीर्ष-स्तरीय प्रतिनिधित्व नहीं है।

दूसरे शब्दों में F का हस्ताक्षर हमेशा होता है:

declare function F(...args: any[]): ClassDecorator | PropertyDecorator | MethodDecorator | ParameterDecorator;

या कुछ समकक्ष।

फिर आह्वान @F को कंपाइलर द्वारा @F() के बराबर बनाया जाता है। चूँकि @F और @F() दोनों के हस्ताक्षर किसी न किसी रूप में कारखाने के हस्ताक्षर से मेल खाने चाहिए, इससे मंगलाचरण भ्रम की समस्या हल हो जाती है। डेकोरेटर को आमंत्रित करने का केवल एक ही तरीका है!

निम्नलिखित को देखते हुए:

declare function F(...args: any[]): PropertyDecorator {
    return (target, name) => {
        // do stuff.
    }
}

@F()
property: number;

तथा

declare function F(target, name) { // Matches PropertyDecorator
    // do stuff.
}

<strong i="22">@F</strong>
property: number;

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

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

@ डेविड साउथर क्या कोई वैध कारण है कि ऐसा क्यों नहीं हो सकता है या नहीं होना चाहिए? @F और @F() आह्वान के बीच कोई कार्यात्मक अंतर नहीं है, लेकिन उन्हें परिभाषित और प्रलेखित करने के बीच एक बहुत बड़ा अंतर है, और यह आह्वान में अतिरिक्त जटिलता जोड़ता है जो अनावश्यक होना चाहिए।

मेरा प्रस्ताव है कि डेकोरेटर को परिभाषित करने के दो तरीके नहीं होने चाहिए क्योंकि इसकी कोई आवश्यकता नहीं है, और एक डेकोरेटर को एक से अधिक तरीकों से परिभाषित करने की आवश्यकता नहीं होनी चाहिए।

@F और @F() के आह्वान के बीच कोई कार्यात्मक अंतर नहीं है

मुझे लगता है कि यह विवाद का मुख्य बिंदु है। मुझे नहीं लगता कि यह सच है। F एक फ़ंक्शन का संदर्भ है, F() एक खाली तर्क सेट (यानी F.call(this, []) ) के साथ कॉल किए जाने पर F के रिटर्न मान का संदर्भ है; और ये दो कार्यात्मक रूप से, और अवधारणात्मक रूप से भिन्न चीजें हैं।

@Tharaxis @F और @F() अलग चीजें हैं। उनके उपयोग के तरीके में अंतर है, उन्हें कैसे प्रलेखित किया जाता है, और उनके आह्वान में अंतर है जो कि नितांत आवश्यक है।

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

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

@ डेविड साउथर आपका प्रश्न इस बात पर निर्भर करता है कि आप एक साधारण सजावटी के रूप में क्या परिभाषित करते हैं। एक साधारण डेकोरेटर के रूप में कुछ भी नहीं रोकता है:

declare function F(): PropertyDecorator {
    return (target, name) => {
        // do stuff
    }
}

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

इसके अतिरिक्त एक अधिक समस्याग्रस्त समस्या इस प्रकार है:

declare function F(options?: any): PropertyDecorator {
    return (target, name) => {
        // do stuff
    }
}

@F()
property1: number;

<strong i="15">@F</strong>
property2: number;

@F({ option: true })
property3: number;

इनमें कुछ चीजें एक जैसी नहीं हैं। @F का उपयोग काम नहीं करेगा, भले ही अंकित मूल्य पर यह निश्चित रूप से होना चाहिए। ध्यान रखें, दिखावा करें कि मैं कोई ऐसा व्यक्ति हूं जिसे इस बात की जानकारी नहीं है कि F की अंतर्निहित घोषणा कैसी दिखती है, लेकिन इसके बजाय बस यह जान लें कि F मौजूद है और यह तर्कों का एक वैकल्पिक सेट ले सकता है। मेरे द्वारा @F साथ गलती करने की संभावना मौजूदा तंत्र के तहत मामूली नहीं है। यह यह सुनिश्चित करने के लिए डेवलपर/दस्तावेज़कर्ता पर एक बड़ा दायित्व डालता है कि उपभोक्ता को पता है कि @F काम नहीं करेगा (लेकिन शायद @C होगा क्योंकि यह किसी भी तरह "अलग" है)।

अगर मुझे "एक आकार सभी फिट बैठता है" डेकोरेटर चाहिए, जहां उपभोक्ता को चिंता करने की ज़रूरत नहीं है, तो मुझे यह भयानक काम करना होगा:

declare function F(...args: any[]): any {
    var decorator = (target, name) => {
        // do stuff
    }

    // Heaven forbid your decorator formal parameter list also can take 2 parameters.
    return (args.length === 2) ? decorator(args[0], args[1]) : decorator;
}

जो कि काफी भयावह है। इसके अतिरिक्त, मैं डेकोरेटर एफ के खिलाफ सभी मूल्यवान पैरामीटर इंटेलिजेंस खो देता हूं क्योंकि अब इसे सामान्यीकृत किया जाना है।

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

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

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

साथ ही, मैंने डेकोरेटर्स के लिए टाइप चेकिंग में विसंगतियों के संबंध में आपके पहले के बिंदु को संबोधित करने के लिए पीआर #3249 जमा किया है।

हाय @rbuckton ,

मैं उन लोगों में से एक हूं जो @Tharaxis द्वारा उल्लिखित सज्जाकारों के इतने जानकार उपयोगकर्ता नहीं हैं ...

मुझे लगता है कि मेरे पास यह प्रश्न होगा कि क्या सज्जाकार कार्यों के अनुरूप होना चाहिए? यानी कार्यों के मामले में, this.f बनाम this.f() वापस करना मेरे लिए पूरी तरह से समझ में आता है क्योंकि कभी-कभी मुझे मूल्य चाहिए, कभी-कभी मुझे वह चीज़ चाहिए जो मूल्य उत्पन्न करती है।

सज्जाकारों के मामले में यह भाषा सुविधा स्तर पर मेरे लिए बिल्कुल स्पष्ट नहीं है। मैं यह तर्क देना चाहूंगा कि मैं सिर्फ डेकोरेटर @F लागू करना चाहता

मेरी क्षमा याचना अगर उपरोक्त गलत या अज्ञानी है, तो मैं जावास्क्रिप्ट की दुनिया में अपेक्षाकृत नया हूं।

धन्यवाद और चीयर्स

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

अभी यह तथ्य कि @F और @F() समान नहीं हैं, निम्नलिखित मुद्दों का कारण बनते हैं:

• डेवलपर्स को @F और @F() बीच अंतर को समझने की जरूरत है और कभी-कभी यह क्यों काम कर सकता है और कभी-कभी यह काम क्यों नहीं कर सकता है (और @F बनाम @F() का उपयोग करने की आवश्यकता declare function A(params?: any): ParameterDecorator बनाम declare function B(target, name) , @A काम नहीं करेगा, लेकिन @A() होगा, @B काम करेगा लेकिन @B() काम नहीं करेगा, फिर भी संज्ञानात्मक रूप से वे एक ही चीज हैं, बिना किसी तर्क के डेकोरेटर का एक आवेदन)।
• कोड स्तर से समस्या को हल करने के लिए एक कठोर समाधान की आवश्यकता होती है जो डेकोरेटर के आमंत्रण वाक्यविन्यास को पर्याप्त रूप से दस्तावेज करने की क्षमता को हटा देता है।
• यदि आपने 'रॉ डेकोरेटर' ( @F ) बनाया है और अब आप कुछ पैरामीटर जोड़ना चाहते हैं (लेकिन उन्हें पश्चगामी संगतता के लिए वैकल्पिक बनाएं) तो रिफैक्टरिंग थोड़ा अधिक काम है। वर्तमान पद्धति के तहत, वे सभी @F लागू होते हैं, जिन्हें अब @F() पुन: सक्रिय करने की आवश्यकता होगी - कुछ कोड के भीतर जिनकी आपकी पहुंच नहीं हो सकती है - जबकि निहित आह्वान आपको चीजों को काम करने और प्रतिबंधित करने की अनुमति देगा अपने कोड में बदलें।

@ थारैक्सिस मैं समझता हूं कि @F और @F() बीच का अंतर उपभोक्ताओं पर एक उच्च संज्ञानात्मक बोझ हो सकता है। हालांकि, ऐसा लगता है कि आप उत्सर्जित कोड, और इसलिए व्यवहार को बदलने के लिए कह रहे हैं, ताकि दोनों समान व्यवहार करें। यह संभवतः सज्जाकारों के लिए ES7 प्रस्ताव के साथ संघर्ष करेगा, क्योंकि दो रूपों के समान व्यवहार किए जाने की संभावना बहुत कम है। यह अच्छा नहीं होगा यदि यह विचलन की ओर ले जाता है।

एक और बिंदु यह है कि यहां भ्रम एक फ़ंक्शन को कॉलबैक के रूप में पास करने और फ़ंक्शन को कॉल करने के बीच भ्रम के समान है। यदि आपके पास यह था

function callbackFactory() {
     return function(...args: any[]) { // do stuff };
}
function takesCallback(cb: (...args: any[]) => void) { }
takesCallback(callbackFactory());

कोई उपयोगकर्ता भ्रमित हो सकता है और takesCallback(callbackFactory) कॉल किए बिना callbackFactory कॉल कर सकता है। यह वास्तव में भ्रम की तरह है जिसे आपने सज्जाकारों के साथ बताया था, लेकिन अगर भाषा ने इन दो रूपों को एक ही काम करने के लिए सामान्यीकृत किया, तो अभिव्यक्ति में कमी आएगी। कभी-कभी भेद महत्वपूर्ण होता है, और इसे बनाए रखने की आवश्यकता होती है। निश्चित नहीं है कि यह आमतौर पर सज्जाकारों के लिए भी लागू होता है, लेकिन सिद्धांत रूप में यह निश्चित रूप से हो सकता है।

@JsonFreeman हालांकि मुझे वास्तव में आपका तर्क नहीं मिला है। आप कह रहे हैं कि आप डेकोरेटर्स को अपनी इकाई के रूप में समझ नहीं सकते क्योंकि डेकोरेटर्स के लिए एक ES7 प्रस्ताव मौजूद है, लेकिन यह बात है, ES7 डेकोरेटर बस यही हैं, एक _प्रस्ताव_, और जहां तक ​​​​मुझे पता है, वे ' आंशिक रूप से Google और आपके द्वारा वर्णित डेकोरेटर कार्य के संयोजन पर आधारित हैं, है ना? अभी तक कुछ भी तय नहीं किया गया है कि उन्हें कैसे काम करना है, और यह संभावना है कि प्रस्ताव अनुमोदन से पहले _many_ पुनरावृत्तियों से गुजरेगा, तो क्यों न उन्हें टीएस में लगातार तरीके से काम किया जाए और फिर (कम से कम कोशिश करें) प्राप्त करें आधार के रूप में टीएस में प्राप्त अनुभव का उपयोग करते हुए, विचार के पीछे प्रस्ताव में शामिल विभिन्न पक्ष? यह पहली बार नहीं होगा जब TS ने केवल बाद में रिफैक्टर करने के लिए एक सुविधा लागू की है क्योंकि ES6 युक्ति को थोड़ा अलग व्यवहार के लिए कहा जाता है। आपको यह समस्या तब तक _हमेशा_ होगी जब तक आप किसी ऐसी युक्ति के विरुद्ध ट्रैकिंग कर रहे हैं जो अभी तक मौजूद नहीं है और जिस पर अभी तक सहमति नहीं बनी है।

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

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

@mhegazy यह वही मुद्दा मैं यहाँ @jonathandturner डेकोरेटर रेपो पर लाया है: https://github.com/jonathandturner/decorators/issues/16 मैं इस बारे में सोच कर कुछ है कि के बारे में सोचा जाना चाहिए। जैसा कि यह खड़ा है, मुझे उम्मीद है कि यह डिज़ाइन विकल्प कई ब्लॉग पोस्ट का विषय होगा, जिसका शीर्षक "ES7 डेकोरेटर नुकसान" भी है।

@ थारैक्सिस , मैं आपके पहले बिंदु से सहमत हूं। मुझे नहीं लगता कि एक ES7 प्रस्ताव हमें कुछ अच्छी तरह से डिजाइन करने से रोकना चाहिए, और हमारा डिजाइन वास्तव में ES7 के अग्रदूतों में से एक है।

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

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

@JsonFreeman तर्क वर्तमान स्थिति के इर्द-गिर्द घूमता है जहाँ एक डेकोरेटर का वर्णन करने और उसे आमंत्रित करने के दो तरीके हैं, एक फ़ैक्टरी फ़ंक्शन के माध्यम से, और फिर एक "रॉ" फ़ंक्शन के रूप में (जो फ़ैक्टरी मामले में फ़ैक्टरी कॉल का परिणाम है) ), और सवाल इस बारे में अधिक था कि "क्या सिर्फ एक ही रास्ता नहीं होना चाहिए, और क्या कारखाने इस तरह से होने चाहिए"।

मैं जो पूछ रहा हूं वह हां है, क्या हमारे पास कंपाइलर @F को @F() कॉल के बराबर में नहीं बदल सकता है और टाइप चेकिंग के लिए 0 की तर्क सूची की आवश्यकता होती है ... एन पैरामीटर का उपयोग करते समय अखंड वाक्य रचना। शायद आप इस बारे में विस्तार से बता सकते हैं कि "... प्रोग्रामर के लिए डेकोरेटर फैक्ट्री और डेकोरेटर के बीच अंतर करने का कोई तरीका नहीं होगा ...", क्योंकि मुझे लगता है कि यह अंतर करना बहुत आसान है। डेकोरेटर हमेशा कारखाने से प्रतिक्रिया करता है, और कारखाने का नाम डेकोरेटर का नाम है ... इतना मुश्किल नहीं है, या क्या मैं गलत समझ रहा हूँ?

उपभोक्ता को केवल डेकोरेटर लागू करने की अनुमति देने के बारे में आपके अंतिम बिंदु के रूप में, यदि यह अच्छी तरह से वर्णित है कि सभी सज्जाकार कारखानों का उपयोग करते हैं, तो यह बहुत आसान है कि आप स्वयं एक डेकोरेटर को आमंत्रित करें, आप <decorator name>(<argument list>)(target, name) की तुलना में बस <decorator name>(target, name) एक उदाहरण के रूप में। ध्यान रखें कि कारखानों के उपयोग को अनिवार्य करने का मतलब होगा कि पूर्व उदाहरण हमेशा काम करेगा, जबकि इसे अनिवार्य नहीं करने के परिणामस्वरूप बाद वाला उदाहरण कभी-कभी काम नहीं करेगा, और यह पूरी तरह से इस बात पर निर्भर करता है कि डेकोरेटर कैसे लागू किया जाता है - एक सिरदर्द बस होने की प्रतीक्षा कर रहा है।

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

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

हाय सब, @Tharaxis ने जो कहा है,

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

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

आदर्श रूप से यह बहुत अच्छा होगा यदि @F और @F() सजावटी कैसे लागू किए जाते हैं, इस पर ध्यान दिए बिना संगत हो सकते हैं, लेकिन यदि नहीं तो मैं घास में रेक से बचने के बजाय सजावटी लिखते समय कारखानों का उपयोग करने के लिए बाध्य होना पसंद करूंगा जब भी मैं उनका उपयोग कर रहा हूं।

धन्यवाद और चीयर्स

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

यह विचार ऐसा लगता है कि यह डेकोरेटर्स और डेकोरेटर कारखानों की प्राकृतिक संरचना को उलट देगा। सज्जाकार निश्चित रूप से यहाँ आदिम निर्माण की तरह महसूस करते हैं, जिसमें डेकोरेटर कारखाने सज्जाकारों के ऊपर निर्मित अमूर्तता की एक परत होते हैं। वे सिर्फ एक पैटर्न हैं, इससे ज्यादा कुछ नहीं। यदि इसके बजाय डेकोरेटर फैक्ट्री विहित चीज, आदिम बन जाती है, तो लोग डेकोरेटर कारखानों के एक समूह को परिभाषित करेंगे, जो कोई तर्क नहीं लेते हैं और एक फ्लैट डेकोरेटर लौटाते हैं। यह बहुत मूर्खतापूर्ण लगने लगेगा, और यह उस प्राकृतिक अंतर्ज्ञान को उलट देगा जिसे बुनियादी माना जाता है और जिसे अधिक जटिल माना जाता है।

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

हाय @JsonFreeman ,

जैसा कि मैंने उल्लेख किया है कि मेरी प्राथमिकता हमेशा उपयोगकर्ता के बजाय डेकोरेटर के लेखक के साथ कुरूपता के लिए होगी। हालांकि, मैं मानता हूं कि बहुत सारे बिना तर्क वाले कारखाने पूरी तरह से बदसूरत हैं। क्या इसे ठीक करने के लिए डेकोरेटर का इस्तेमाल किया जा सकता है? उदाहरण के लिए

// wraps rawDecoratorMethod in a no-arg factory method.
<strong i="8">@Decorator</strong>
function rawDecoroatorMethod(target, name, descriptor) {...}

// looks like this one would be a no-op... so that feels not quite right unless there's other advantages.
<strong i="11">@DecoratorFactory</strong>
function decoroatorFactoryMethod(someArg) {...}

वैसे भी, अगर इस तरह के दृष्टिकोण को समझने के लिए पाया जा सकता है तो इसका लाभ यह है कि एनोटेशन फ़ंक्शन के उद्देश्य को दस्तावेज करता है। यानी सजाता है।

चियर्स

अच्छी ग्रेवी, डेकोरेटर्स डेकोरेटर्स को परिभाषित करने में मदद करने के लिए, टाइपसेप्शन का एक गंभीर मामला।

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

दूसरा विकल्प यह है कि सज्जाकार जिन्हें @F कहा जाता है, वे ClassDecorator, MethodDecorator, PropertyDecorator या ParameterDecorator के पैटर्न से मेल खाने में सक्षम हैं, या एक 0..n arg फ़ैक्टरी फ़ंक्शन जो ClassDecorator, MethodDecorator, PropertyDecorator देता है या पैरामीटर डेकोरेटर। हालांकि मुझे लगता है कि कार्यान्वयन अन्य त्रुटियों का कारण होगा (क्या होगा यदि आपके पास दो विरोधाभासी कार्य हैं, जिन्हें सर्वोत्तम संभव मिलान माना जाएगा?) और संकलक के भीतर केवल अनुचित जटिलता जोड़ देगा। बस @F कॉल को @F() कनवर्ट करना आसान समाधान होगा और बताई गई विभिन्न समस्याओं का समाधान करेगा।

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

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

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

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

क्या आप विस्तार से बता सकते हैं कि एक मनमाना डेकोरेटर अभिव्यक्ति से आपका क्या मतलब है?

अच्छी ग्रेवी, डेकोरेटर्स डेकोरेटर्स को परिभाषित करने में मदद करने के लिए, टाइपसेप्शन का एक गंभीर मामला।

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

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

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

मैं यह भी नहीं देखता कि f और f() का उपयोग करते समय आपको यह परिदृश्य मिलेगा, वे उपभोग पक्ष पर अलग-अलग उपयोग के मामले हैं। डेकोरेटर मामले में मैं हमेशा डेकोरेटर को लक्ष्य पर लागू/आह्वान कर रहा हूं, और दृश्यों के पीछे हमेशा एक विधि आमंत्रण चल रहा है।

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

चियर्स

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

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

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

चियर्स

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

@(F || function (target) { // default decorator behavior })
class C { }

क्या आप स्वचालित रूप से इसका आह्वान करते हैं? यह आपको गलत परिणाम देगा क्योंकि आप इसे लागू करने से पहले डिफ़ॉल्ट डेकोरेटर को लागू करना समाप्त कर देते हैं:

(F || function (target) { // default decorator behavior })()

यह सही नहीं लगता।

@JsonFreeman , क्या डेकोरेटर सिंटैक्स इस तरह की मनमानी अभिव्यक्तियों की अनुमति देता है? मैं 100% निश्चित नहीं हूं कि डेवलपर्स को इतनी रस्सी जिसके साथ खुद को लटका देना जरूरी है, एक अच्छा विचार है, लेकिन यह सिर्फ मुझे है (विशुद्ध रूप से क्योंकि मुझे मनमाने ढंग से अभिव्यक्ति नहीं दिखती है जैसे कि पुन: उपयोग/बॉयलरप्लेट समस्या को हल करना डेकोरेटर का लक्ष्य है हल करना और इसके बजाय कोड को बदसूरत और अनुसरण करने में और भी कठिन बनाने के लिए काम करें)।

उस ने कहा, मुझे लगता है कि यह काम करने का एकमात्र तरीका होगा यदि मनमानी अभिव्यक्ति स्वयं उसी फैक्ट्री सिंटैक्स का मूल्यांकन करती है, इसलिए:

@(F || () => function(target) { /* default decorator behaviour */ })
class C { }

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

नोट: मेरा स्पष्ट रूप से यह मतलब नहीं था कि लैम्ब्डा सिंटैक्स इसे घोषित करने का एकमात्र तरीका होगा, लेकिन () => से थोड़ा अच्छा है function() { return function(target) { /*...*/ } } ।

सिंटैक्स डिबेट को कॉल करने वाले इस डेकोरेटर को बाधित करने के लिए वास्तव में खेद है, लेकिन क्या कोई आधिकारिक तौर पर उस ऑर्डर को स्पष्ट कर सकता है जिसे डेकोरेटर एक्सप्रेशन कहा जाता है? विशेष रूप से, डेकोरेटर लक्ष्य प्रकार की तर्ज पर, मूल स्रोत में लक्ष्य सदस्य की स्थिति और एक लक्ष्य पर सज्जाकारों का क्रम।

@billccn डेकोरेटर नीचे से ऊपर तक

class C {
    <strong i="7">@F</strong>
    <strong i="8">@G</strong>
    method() { }
}

यह पहले G को विधि पर लागू करेगा, और फिर F को परिणाम पर लागू करेगा। क्या आप यही पूछ रहे हैं?

इसके लिए कैसे:

<strong i="6">@A</strong>
class Clazz {
    <strong i="7">@B</strong>
    prop = 1;

    <strong i="8">@C</strong>
    method() {}

    <strong i="9">@D</strong>
    get prop() {return 1;}

    <strong i="10">@E</strong>
    method2() {}

    <strong i="11">@F</strong>
    prop2 = 1;
}

वे स्कोप ऑर्डर का पालन करते हैं, इसलिए सभी गुण/विधियां पहले घोषणा के क्रम में, फिर कक्षा एक। यानी बी, सी, डी, ई, एफ, ए।

आप यहां जेनरेट कोड देख सकते हैं।

ऐसा लगता है कि पैरामीटर गुणों को सजाने के लिए वर्तमान में संभव नहीं है। क्या उनका समर्थन किया जा सकता है?

पैरामीटर गुण constructor(private prop: Type) जैसी चीजें हैं, जहां एक संपत्ति (फ़ील्ड) और पैरामीटर को एक साथ घोषित किया जाता है। समस्या यह है कि दोनों को सजाया जा सकता है, इसलिए कुछ कल्पनाशील वाक्य-विन्यास का आविष्कार करना पड़ सकता है।

प्रश्न: क्या डेकोरेटर्स का उपयोग प्लेन ऑब्जेक्ट मेथड के व्यवहार को संशोधित करने के लिए किया जा सकता है, जैसे...

var isCreatorUser = () => {  /* code that verifies if user is the creator */ },
    isAdminUser = () => { /* code that verifies if user is admin */ },

var routeConfig = {
    get() {},
    <strong i="7">@isCreatorUser</strong> patch() {},
    <strong i="8">@isAdminUser</strong> <strong i="9">@isCreatorUser</strong> delete() {}
};

... और यदि नहीं, तो क्यों? यह वास्तव में उपयोगी होगा।

अभी नहीं, लेकिन हम इस पर विचार कर रहे हैं। @rbuckton में अधिक जानकारी हो सकती है।

क्या मैं पूछ सकता हूं कि डेकोरेटर सजाए गए प्रकार से सजाए गए परिणाम प्रकार को क्यों नहीं बदल सकता है?

उदाहरण के लिए, मेथडडेकोरेटर को वैकल्पिक रूप से नीचे प्रस्तावित किया जा सकता है:

declare type MethodDecorator = <T, R>(target: Object, propertyKey: string | symbol, descriptor: TypedPropertyDescriptor<T>) => TypedPropertyDescriptor<R> | void;

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

मुझे पता है कि https://github.com/jonathandturner/brainstorming/blob/master/README.md#c4 -defining-a-decorator ने कहा है कि रिटर्निंग प्रकार समान होना चाहिए। लेकिन type validity यहां वैध तर्क नहीं है, आईएमएचओ। सबसे पहले, जावास्क्रिप्ट में डेकोरेटर वर्ग/फ़ील्ड प्रकार को बदल सकते हैं, इसलिए टीएस और जेएस के बीच कोई संगतता समस्या नहीं है। दूसरे, डेकोरेटर्स को स्थिर रूप से लागू किया जाता है, टीएस कंपाइलर परिभाषित साइट पर मूल फ़ील्ड प्रकार और डेकोरेटेड फ़ील्ड प्रकार के बारे में तर्क कर सकता है।

@HerringtonDarkholme मैं कहूंगा कि इसे एक अलग सुझाव में ट्रैक करने की जरूरत है। मुख्य कारण यह है कि संकलक प्रकार के बारे में कारण घोषणाओं के माध्यम से होता है। एक बार एक प्रकार घोषित हो जाने पर यह बदल नहीं सकता है। मिश्रण में टाइप म्यूटेटर जोड़ने का मतलब है कि हमें इन्हें हल करने की आवश्यकता है क्योंकि हम घोषणा को हल कर रहे हैं जो बालों वाली हो सकती है।

@mhegazy तो, क्या मैं इसे जानबूझकर डिजाइन के बजाय कार्यान्वयन में आसानी के लिए एक समझौता के रूप में समझ सकता हूं?

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

function SafeCtor(target) {
  var safe = function(...args) {
    var instance = Object.create(target.prototype)
    target.call(instance, ...args)
    return instance
  }
  safe.prototype = target.prototype
  return safe
}

<strong i="10">@SafeCtor</strong>
class Snake {
  constructor(name) {
    this.name = name
  } 
}

var snake = Snake('python')
alert(snake instanceof Snake)

मुझे पता है कि इस सुविधा का समर्थन करने की संभावना कम है। लेकिन मैं पुष्टि करना चाहता हूं कि यह structural बनाम nominal टाइपिंग जैसी कहानी नहीं है।

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

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

हालांकि मुझे लगता है कि वास्तव में हमें डेकोरेटर रिटर्न टाइप और टारगेट को एक मिक्सिन की तरह मर्ज करना चाहिए।

बस कुछ अतिरिक्त कार्यक्षमता विचार। चूंकि टाइपस्क्रिप्ट कंपाइलर आउटपुट जावास्क्रिप्ट है, जावा के लिए कुछ समान भाषाएं हैं, जैसे Xtend

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

डेकोरेटर्स के माध्यम से टाइपस्क्रिप्ट आउटपुट को नियंत्रित करना वास्तव में एक अच्छी सुविधा होगी!

इंटरफेस के लिए सज्जाकार, संभव होना चाहिए।

@shumy समस्या यह है कि इंटरफेस किसी भी तरह से रनटाइम पर मौजूद नहीं होते हैं, और डेकोरेटर विशुद्ध रूप से रनटाइम पर चलते हैं।

क्या रिटर्न वैल्यू के संबंध में मेथड डेकोरेटर्स की तुलना में प्रॉपर्टी डेकोरेटर्स के साथ अलग व्यवहार करने का कोई कारण है? (बेबेल नहीं करता)।

मेरा मतलब यह है कि, अगर मैं डेकोरेटर के माध्यम से किसी संपत्ति के लिए कार्यक्षमता को परिभाषित करना चाहता हूं तो मुझे यह करना होगा:

function decorator(proto, name) {
    Object.defineProperty(proto, name, { value: 42 });
}

class Foo {
    <strong i="7">@decorator</strong>
    a: number;
}

जबकि बाबेल को विवरणक को वापस करने की आवश्यकता है:

function decorator(proto, name) {
    return { value: 42 };
}

class Foo {
    <strong i="11">@decorator</strong>
    a;
}

इससे टाइपस्क्रिप्ट में एक डेकोरेटर लिखना मुश्किल हो जाता है जो एक पुस्तकालय का हिस्सा है जिसका उपयोग बैबेल से किया जाएगा।

मैं प्रस्ताव दूंगा कि एक प्रॉपर्टी डेकोरेटर को मेथड डेकोरेटर के समान माना जाए, और डेकोरेटर का रिटर्न वैल्यू Object.defineProperty माध्यम से लागू किया जाना चाहिए। यह एक विधि की तरह, एक ही संपत्ति पर कई सज्जाकारों के लिए भी अनुमति देगा।

अभी के लिए वर्कअराउंड (बेबेल संगतता के लिए) संपत्ति को सेट करने के अलावा डेकोरेटर से डिस्क्रिप्टर को वापस करना है, लेकिन यह अनावश्यक रूप से बेकार लगता है:

function decorator(proto, name) {
    var d = { value: 42 };
    Object.defineProperty(proto, name, d);
    return d;
}

@mhegazy क्या आपको उपरोक्त मेरी टिप्पणी पर कोई अंतर्दृष्टि होगी?

@sccolbert टाइपस्क्रिप्ट में हमने डेटा गुणों पर सज्जाकारों के लिए संपत्ति वर्णनकर्ताओं के उपयोग को अस्वीकार करने का विकल्प चुना है, क्योंकि यह इस तथ्य के कारण रनटाइम पर समस्याएँ पैदा कर सकता है कि वर्णनकर्ता द्वारा निर्दिष्ट कोई भी "मूल्य" प्रोटोटाइप पर सेट किया जाएगा, न कि उदाहरण पर . जबकि ऊपर आपका उदाहरण आम तौर पर कोई मुद्दा नहीं होगा, निम्नलिखित पर विचार करें:

function decorator(proto, name) {
  return { value: new Point(0, 0); }
}

class Foo {
  <strong i="7">@decorator</strong>
  p: Point;

  setX(x) { this.p.x = 1; }
}

let a = new Foo();
let b = new Foo();
console.log(a.p.x); // 0
b.setX(10);
console.log(a.p.x); // 10 (!)

डिस्क्रिप्टर पर "इनिशियलाइज़र" प्रॉपर्टी का समर्थन करने के लिए ईएस के भविष्य के संस्करण के लिए एक प्रस्ताव है, जिसका मूल्यांकन कंस्ट्रक्टर के दौरान किया जाएगा। इससे आपको यह नियंत्रित करने की क्षमता मिल जाएगी कि मान प्रोटोटाइप पर सेट है या प्रति-आवंटित आवंटित किया गया है।

अभी के लिए आप अपनी टिप्पणी में उदाहरण के अनुसार सीधे Object.defineProperty कॉल करके इस सीमा के आसपास काम कर सकते हैं। हम इस बात की जांच करना जारी रखेंगे कि भविष्य में इस प्रतिबंध में ढील दी जाए या नहीं।

@rbuckton धन्यवाद! क्या आप लोग समान शब्दार्थ पर अभिसरण करने के लिए बाबेल के साथ बातचीत कर रहे हैं? मुझे लगता है कि यह सबसे महत्वपूर्ण बात है।

किसी विशेष उदाहरण के लिए मान निर्दिष्ट करने के लिए डेकोरेटर का उपयोग करना क्यों उपयोगी होगा? क्या यह नहीं है कि संपत्ति प्रारंभकर्ता क्या है?

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

आप इसे पायथन में डिस्क्रिप्टर प्रोटोकॉल का अनुकरण करने के रूप में सोच सकते हैं, जहां एक्सेस विधि bar को कक्षा Foo पर परिभाषित किया गया है, उदाहरण के लिए foo (यानी foo.bar ) __get__ फ़ंक्शन की विधि जो BoundMethod लौटाती है। जब उस ऑब्जेक्ट को कॉल किया जाता है, तो अंतर्निहित फ़ंक्शन को पहले तर्क के रूप में self साथ बुलाया जाता है, जो इस मामले में foo । जावास्क्रिप्ट में यह अवधारणा नहीं है, यही कारण है कि हमें लगभग thisArg पास करना पड़ता है और function.bind को पूरे स्थान पर कॉल करना पड़ता है।

मेरे मामले के लिए, मैं विधियों को परिभाषित नहीं कर रहा हूं, बल्कि एक प्रकार-सुरक्षित संकेत हूं। यहाँ डेकोरेटर है:
https://github.com/phosphorjs/phosphor-signaling/blob/1.0.1/src/index.ts#L144

जब संपत्ति का उपयोग किया जाता है, तो यह ISignal का कार्यान्वयन देता है जो मालिक के this संदर्भ से जुड़ा होता है। यह सिग्नल को उस उदाहरण को वापस संदर्भित करने की अनुमति देता है जिस पर इसे परिभाषित किया गया था:
https://github.com/phosphorjs/phosphor-signaling/blob/1.0.1/src/index.ts#L263

तो असल में, मैं इस वर्बोज़ समकक्ष के शॉर्टकट के रूप में सजावटी का उपयोग कर रहा हूं:

class Foo {
  valueChanged: ISignal<number>;
}

defineSignal(Foo.prototype, 'valueChanged');

@rbuckton

ES3 को लक्षित करते समय सज्जाकारों की अनुमति नहीं है

क्यों? मैं ऐसा कुछ भी नहीं देख सकता जो ES3 में __decorate के उपयोग को रोक सके।

यह संपत्ति विवरणक का उपयोग करता है, जो ES3 में उपलब्ध नहीं है
ले 4 सितंबर २०१५ २:०३ अपराह्न, "कोलोटो" नोटिफिकेशन @github.com एक लेख :

@rbuckton https://github.com/rbuckton

ES3 को लक्षित करते समय सज्जाकारों की अनुमति नहीं है

क्यों? मैं ऐसा कुछ भी नहीं देख सकता जो ES3 में __decorate के उपयोग को रोक सके।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/Microsoft/TypeScript/issues/2249#issuecomment -137717517
.

@sccolbert आप इसके लिए संपत्ति सज्जाकारों के बजाय ES6 परदे के पीछे बेहतर कर सकते हैं।

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy

@ डेविड साउथर ब्राउज़र अभी तक प्रॉक्सी का समर्थन नहीं करते हैं :(

@cybrown हां, यह विधियों और

और ES3 को लक्षित करते समय विधियों के लिए एक नकली संपत्ति विवरणक का उपयोग किया जा सकता है। { writable: true, enumerable: true, configurable: true } जैसा कुछ। इसलिए मुझे ES3 का समर्थन न करने का कोई कारण नहीं दिख रहा है।

@sccolbert मैं देखता हूं। यह समझ आता है। संयोग से, टाइपस्क्रिप्ट कार्यों और विधियों के लिए बेहतर _this_ टाइपिंग पर काम कर रहा है। मुझे आश्चर्य है कि क्या इससे यहां कोई मदद मिलेगी। हालांकि मुझे लगता है कि टाइपिंग आपके लिए मुद्दा नहीं है, यह रनटाइम सेमेन्टिक्स है।

@JsonFreeman बेहतर _this_ टाइपिंग मेरे कुछ अन्य उपयोग मामलों के लिए दिलचस्प लगता है। क्या आपके पास इसके बारे में और जानकारी है?

मुझे लगता है कि _this_ टाइपिंग पर सबसे विकसित चर्चा #3694 पर है।

चीयर्स!

त्रुटि TS1207: सज्जाकारों को एक ही नाम के एकाधिक प्राप्त/सेट एक्सेसर्स पर लागू नहीं किया जा सकता है।

<strong i="6">@get</strong>
public get myValue():any{...}

<strong i="7">@set</strong>
public set myValue(value:any){...}

उपरोक्त कोड की अनुमति नहीं है, यहां तक ​​​​कि यह तुलना करने के लिए और अधिक समझ में आता है

<strong i="11">@get</strong>
<strong i="12">@set</strong>
public get myValue():any{...}

public set myValue(value:any){...}

गेट्टर और सेटर को एक कॉल में Obect.defineProperty पर परिभाषित किया गया है। यह एक जेएस क्विर्क है, सेट की घोषणा और अलग होने के बावजूद, वास्तव में एक ही संपत्ति घोषणा है। कंपाइलर में त्रुटि जांच उपयोगकर्ताओं को उनके बारे में अलग से सोचने पर सचेत करना है; डेकोरेटर केवल एक बार प्रॉपर्टी डिस्क्रिप्टर पर लागू होते हैं।

बस सोच रहा था क्योंकि संकलक एक ही नाम से प्राप्त और सेट को समझ सकता है और एकल ऑब्जेक्ट में गठबंधन कर सकता है। परिभाषित प्रॉपर्टी, सजावटी को भी क्यों न मिलाएं?
या शायद एक विकल्प ध्वज संकलक को उन्हें संयोजित करने के लिए कहने के लिए, और त्रुटि फेंकने के बजाय एक चेतावनी संदेश छोड़ दें।

धन्यवाद

@TakoLittle : आज हम ऐसा नहीं करने का कारण आंशिक रूप से इस बात से उपजा है कि सज्जाकार कैसे बनाए जाते हैं। डेकोरेटर गणितीय फ़ंक्शन संरचना के समान सिद्धांतों का पालन करते हैं, जहां (_f_ _g_)(_x_) को _f_(_g_(_x_)) के रूप में बनाया गया है। उसी अर्थ में, यह सोचा जा सकता है कि:

<strong i="7">@F</strong>
<strong i="8">@G</strong>
class X {}

लगभग है:

F(G(X))

जब आप गेटर और सेटर दोनों को सजाते हैं तो सज्जाकारों की संरचना टूट जाती है:

class C {
  <strong i="15">@F</strong>
  set X(value) {}

  <strong i="16">@G</strong>
  get X() {}
}

F और G यहां कैसे रचना करते हैं? क्या यह पूरी तरह से दस्तावेज़ आदेश (यानी F(G(X)) ) पर आधारित है? क्या गेट्टर और सेटर के लिए सज्जाकारों का प्रत्येक सेट अलग है, और फिर दस्तावेज़ क्रम में निष्पादित किया गया है (यानी G(F(X)) )? क्या get और set किसी विशिष्ट आदेश का संकेत देते हैं (यानी get हमेशा set या इसके विपरीत)? जब तक हम 100% निश्चित नहीं हो जाते कि सबसे सुसंगत दृष्टिकोण जो उपयोगकर्ताओं को आश्चर्यचकित नहीं करता है, या एक अच्छी तरह से प्रलेखित दृष्टिकोण है जो डेकोरेटर्स के प्रस्ताव का हिस्सा है जो कम से कम चरण 2 या ईसीएमए -262 के भीतर बेहतर स्वीकृति के साथ है, हमें लगता है कि यह सबसे अच्छा है यहां अधिक प्रतिबंधात्मक और त्रुटिपूर्ण हो क्योंकि यह हमें बाद की तारीख में उस प्रतिबंध को एक ब्रेकिंग परिवर्तन पेश किए बिना आराम करने की अनुमति देता है जो आसानी से किसी का ध्यान नहीं जा सकता है और संभवतः रनटाइम पर अप्रत्याशित व्यवहार हो सकता है।

@rbuckton विस्तृत विवरण के लिए बहुत बहुत धन्यवाद
टीएस टीम बहुत अच्छा काम !! ^^डी

इस के लिए दस्तावेज कहां है? और कार्यान्वयन प्रतिबद्धता को जोड़ने की देखभाल?

धन्यवाद।

@mhegazy कल्पना के नवीनतम संस्करण के कार्यान्वयन पर क्या स्थिति है। मैं समझता हूं कि वहां कुछ बदलाव हैं।

इस समस्या ने प्रस्ताव के मूल संस्करण को ट्रैक किया। चूंकि यह पूरा हो गया है इसलिए हम इस मुद्दे को बंद कर रहे हैं। कल्पना के किसी भी अपडेट के लिए, हम नए मुद्दों को लॉग करेंगे और सभी ब्रेकिंग परिवर्तनों की रूपरेखा तैयार करेंगे। मैं नहीं समझता कि यह प्रस्‍ताव अभी इस स्‍थान पर है कि हम इस पर कूदने के लिए तैयार हों। हम नए प्रस्ताव पर @wycats के साथ मिलकर काम कर रहे हैं।

@omeid , आप https://github.com/Microsoft/TypeScript-Handbook/blob/master/pages/Decorators.md पर प्रलेखन पा सकते हैं।

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

निश्चित रूप से फंक्शन डेकोरेशन की जरूरत है।
क्या कोड में अन्य वस्तुओं को सजाने की भी योजना है?