Typescript: デコレータ

仕様について私が理解していることからすみません、私たちはできません：

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

私は正しいですか？

型のシリアル化はREST引数でどのように機能しますか？

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

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

デコレータの使用は簡単に思えますが、デコレータの宣言に関するセクションは紛らわしいと思いました。 C.4は、デコレータに@decorator注釈を付ける必要があると述べていますが、実際にこれが起こっていることを示す例は1つもありません。

デコレータファクトリは、Bにあるインターフェイスを実装するクラスになることを目的としていますか？

CoverMemberExpressionSquareBracketsAndComputedPropertyNameの解釈を洗練するためのルールは何ですか？

さまざまなポイントで多くの型指定にFunction | Objectがあることに気付きましたが、これらは型チェック時にオブジェクトに縮退します。 そこに機能がある理由は何ですか？

私はDecoratorFunctionとDecoratorFactoryという用語に夢中ではありません。 私はむしろ、GeneratorとGeneratorFunctionを持つジェネレーターの命名法に従いたいと思います。 このスキームでは、DecoratorFunctionの名前をDecoratorに、DecoratorFactoryの名前をDecoratorFunctionに変更します。

装飾された輸出品の場合、 [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

PR＃2399で実装が追加されました

更新：提案が更新され、 @ wycats ES7JavaScriptデコレータへのリンクが追加されました。

それがクラスだけのものになったのは悲しいことです...
また、アンビエントデコレータはスコープから外れましたか？

関数の提案を含む@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では式であるクラス宣言extend句の場合と同じ問題です。 結果はクラス宣言を持ち上げるのではなく、シンボルだけでした（var宣言に似ていますが、関数宣言には似ていません）

Oupsはそれについて考えていませんでした@mhegazyに感謝します。
ただし、関数部分が元の@jonathandturner提案を完全に放棄した理由には、次のルールがありました。

decorated function declarations cannot be hoisted to the containing scope

巻き上げを緩めることは確かに欠点ですが、他の構成のユースケースがある場合にクラスのみの機能に変換することは損害を与える可能性があります。

必要な一連の制約が何を意味しているのかを見てみましょう。

• 装飾された機能を持ち上げる必要があります
• 関数は、利用可能になり次第デコレーションする必要があります-したがって、デコレータアプリケーションを持ち上げる必要があります
• デコレータは、適用する前に定義する必要があります。したがって、デコレータ定義自体（またはデコレータ式によって参照されるすべてのエンティティ）を引き上げる必要があります。
• デコレータ式は、字句的に適用された場所で評価されます-したがって、アプリケーションを持ち上げることはできません

これについて私が見ることができる唯一の解決策は次のとおりです。関数デコレータの場合、 @identifier形式のもののみを許可します。 左側の表現は許可されていません。 さらに、識別子は関数宣言（装飾された関数を含む）への直接参照である必要があります。 スコープ内で行われるすべての機能装飾は、適用された順序でスコープの上部に表示される必要があります。

巻き上げ規則を破る問題は、それが驚くべきことです。 しばらくの間javascriptを書いている場合、字句的に宣言される前に関数宣言が利用可能であると期待します。 一見単純な構文マーカー（デコレーター）を追加することにより、関数宣言のこの基本的な性質が変更されます。

そうは言っても、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に適用されるまでに装飾されません。

したがって、次のいずれかを選択する必要があります。

• 機能は上げられていません
• 装飾されていない関数は引き上げられますが、デコレータアプリケーションは引き上げられません。

私はこれらのどちらも好きではありませんが、他に何も可能だとは思いません。

これがJSの提案です。 そのため、エンジンは式が関数宣言を参照しているかどうかを認識しませんが、静的分析ではわかります。 このことを考慮：

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

dec2 = undefined;

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

うーん！ Javascriptはもはや単純化されていません。 :-)

関数_expressions_でのみ有効にする方が簡単です。

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

関数式またはラムダは引き上げられません。

typescript 1.5.0-alphaのデコレータにこのようなパラメータを含めることは可能ですか？

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

}

あいさつ。

コンストラクターで宣言された型を取得するデコレーターを作成する方法を理解しようとしています。

これが私がやろうとしていることを説明するいくつかのコードですが、それはハードワイヤードです。 クラスDのコンストラクター宣言に応答するために必要です

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の入力または実装は完全には正しくありません。入力から、ターゲットは関数ですが、typescriptを使用している間は、プロトタイプオブジェクトです。
正しいタイプを取得するには、ターゲットパラメータをキャストする必要があります。

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

私はデコレータベースのAPIを使用してExpressのラッパーを作成しました（ただし、任意のWebフレームワークをサポートでき、アダプタインターフェイスが定義されています）： https ：

ClassDecorator、ParameterDecorator、MethodDecoratorを使用しています。

@ cybrown ＃2635のParameterDecoratorの署名を更新しました。これは、現在マスターになっています。

@rbucktonありがとうございます。明日プロジェクトで更新します。

ParameterDecoratorにパラメーターの名前を含めることは可能ですか？
パラメータの名前は、ParameterDecoratorの最初の引数の半分の時間である可能性があるため、これは便利な場合があります。
さらに、それはミニファイアによるパラメータ名マングリングの解決策かもしれません。

私はこれを達成するように頼まれました：

@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はい、実行時型情報（AtScriptで説明されているrtti）があると、イントロスペクションなどの完全に分離された機能であっても、そのような使用法には最適です。

@cmichaelgrahamhttps ： //github.com/Microsoft/TypeScript/pull/2589をご覧ください

@cmichaelgrahamデコレータと連携するメタデータAPIを追加するES7の提案に取り組んでいポリフィルが存在する必要があります。

@rbuckton @cmichaelgrahamもともとは、装飾されているターゲットに基づいて、デコレータに型を挿入するようコンパイラに指示する特別なTypeScriptデコレータの設計がありました。 @parameterTypesだったと思います。より一般的なメタデータAPIを優先して、その機能が削除されていると考えるのは正しいですか？ もしそうなら、私はそれをサポートします。

TypeScriptに関してその状況について少し話していただけますか。 1.5のリリースは予定されていますか？ もしそうなら、コンパイラオプションはどのようになりますか？ 便利なことの1つは、コンストラクター署名のみの型メタデータをコンパイラーに自動的に生成させることです。

@EisenbergEffectデコレータは1.5の一部であり、最新リリースの1.5-alphaで使用を開始できます。

メタデータのサポートについて。 @paramtypesの当初の提案以降、設計が変更されました。 新しい設計では、Reflect.metadaプロポーザルを使用しています。 動作の詳細については、＃2589を参照してください。 また、 @ rbucktonには、ここでメタデータを消費するためのポリフィルがあります： https ：

@mhegazy私はそれを知っています。 ここを参照してください： http ：

メタデータの提案にも精通しています。 私はそれについてフィードバックを提供してきました。 元の@parameterTypesアイデアが削除されているかどうかを知りたかっただけです。

共有してくれた@EisenbergEffectに感謝します。 ：+1：

はい。 @paramtypesの唯一の問題は、型システムによって送信が指示され、グローバルプログラム情報が必要になることです。 これにより、単一モジュールの変換のシナリオが破られます（＃2499を参照）。 もう1つのオプションは、コールサイトに配置することでした。これにより、作成者ではなくデコレータユーザーに多くの作業が追加されます。 そこで、設計図に戻り、代わりにReflect.metadataアプローチに着手しました。

以前のバージョンの提案もご覧になった場合、同じ理由でアンビエント/デザイン時のデコレータを削除する必要がありました。

明確にしていただきありがとうございます。 それはすべて理にかなっています。 リフレクトベースのアプローチが1.5に到達するかどうかについて何か考えはありますか？

はい。 現在マスターにあります。 次のリリースで利用可能になるはずです。 現在、実験フラグ--emitDecoratorMetadataを使用したオプトイン機能です。 装飾されたエンティティにメタデータを追加するだけです。

「装飾されたエンティティにメタデータを追加するだけです」そのアイデアを拡張できますか？ 特別なデコレータが関係していますか？ それとも、デコレータを使用して何かに追加しますか？ 言い換えると、開発者がAureliaのinjectデコレータを使用する場合、それによってコンパイラがメタデータを生成するようになりますか？

開発者がAureliaの注入デコレータを使用する場合、それはコンパイラをトリガーしてメタデータを生成しますか？

はい。

私が意味したのは：

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

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

--emitDecoratorMetadata （にすなわちコールタイプのメタデータを放出するコンパイラreflect.metadata('desing:paramtypes', [Number, String])のために） Fooしかし_not_ Bar 。

それは私たちのために働くでしょう。 次のリリース、おそらく来週に向けて、Reflect.metadataAPIのサポートを準備します。 説明してくれてありがとう！

それで、これのために何が放出されますか？

`` `language = javascript
@inject
クラスFoo {
コンストラクター（a：A、b：B）{}
}

クラスバー{
コンストラクター（a：数値、b：B）{}
}

would it be (for Foo):

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

@cmichaelgrahamはい、それは大まかに生成されるものです。

クレイジークール!!!!

gulp -typescriptを使用してこのリポジトリを構築し

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フレームワークを変更することなく、今日これを簡単に有効にすることができます。 AureliaのDIライブラリにはフックcontainer.addParameterInfoLocatorます。 型を取り、その依存関係を返すことができる関数を渡します。 次のリリース（来週）では、これをコア構成に追加できるため、TypeScript開発者は簡単にオンにできます。 今週のリリースに入れていただろうが、これがまだ変更されていることに気づかなかった。

@EisenbergEffect brilliant !! ：+1：

アノテーションを使用して、オブジェクトのプロパティを監視可能としてマークしました。これにより、プリミティブが監視可能オブジェクトに変換されます（興味のある方は、https：//github.com/mweststrate/MOBservable/commit/8cc7fc0e20c000db660037c8b5c9d944fe4155d9）。

ただし、特にプロパティの場合、アノテーションがクラス自体のコンストラクターではなくプロトタイプに適用されるのは少し不自然に感じました。これは、初期値、またはthis取得するのが難しいことを意味しますthis 。これは、

その上、素晴らしい機能です！

メタデータリフレクションAPIを使用して、単純なプロパティの依存性注入を行うことができました。
必要な変更はhttps://github.com/matjaz/property-DI/commit/2b4835e100b72d954b57d0e656ea524539ac17ebで確認でき

最初に呼び出される生成されたコードの__metadataデコレータであるべきではありませんか？ クラスのメタデータを使用して単純なデオクレーターを作成したかったのですが、最後に__metadata（ 'design：paramtypes'、[TYPES ....]）が呼び出されたため、Reflectからこれらのデータを取得できません。

@ufonあなたが見ているコードを共有できますか？

確かに、ここhttps://gist.github.com/ufon/5a2fa2481ac412117532

編集：
私の悪い、私のコードに他のいくつかの間違いがあり、クラスの初期化後でも型を取得できません

@ufon 、問題が発生するかどうかはわかりません。 __metadataはデコレータリストの最後の項目です。これは、これが最初に実行され、injectが実行される前であることを意味します。

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

ここで、 __decorate定義はreduce権限を使用して、デコレータを逆の順序で実行します。

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

これは、デコレータ（式として）が宣言順に評価されるが、逆の順序で実行されるという仕様に一致するためです。これにより、外部デコレータは内部デコレータからの結果を消費できます。

わかりました、ご迷惑をおかけして申し訳ありません:)私の悪い、私のコードに他のいくつかの間違いがあり、クラスの初期化後でも型を取得できません

どのようにそれらを照会していますか？ Reflect.metadataのポリフィルはありますか？

要旨に追加...
Reflect.getMetadataKeys（House）;
これにより、空の配列が生成されます。

はい、「reflect-metadata」パッケージが必要です

ポリフィルがそれを@ rbucktonはあなたが見てみることができます。

私はそれを手に入れたと思います...
requireはtypescriptのヘルパーコードの後に​​移動されます

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

そのため、var __metadataが初期化されている間、polyfillはまだロードされていません

しかし、生成されたコードの前にこれらの要件を取得することはできません

編集：要点を更新しました..単一モジュールがコンパイルされると、typescriptの生成されたコードは常にファイルの先頭に移動されるため、__ metadataが解決される前にポリフィルをロードする方法はありません

ああ..これはもっと大きな問題です。 それを追跡するために問題＃2811を記録しました

それまでは、別のモジュールでreflect-metadataが必要です（2つのファイルが必要です）。
https://github.com/matjaz/property-DI/を参照して

呼び出しの不整合があるため、可変/オプションのパラメーターを使用してデコレーターを開発するのは非常に困難です。 例として：

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

@F()
prop: number;

前者の場合、Fはパラメーター（target、propertyName、propertyDescriptor）で呼び出されますが、後者の場合、Fはパラメーター（）で呼び出され、内部関数が返される必要があります。内部関数は（target、propertyName、 propertyDescriptor）。

私の_仮定_は、 @ 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]);
}

これは本当の痛みです。

@Tharaxisこの動作は仕様によるものです。 @Fと@F()は同等ではありません。 @FはデコレータF @F呼び出しますが、 @F()は空の引数リストを持つデコレータ係数Fを呼び出し、結果のデコレータを適用します。

ここでの問題は、コンパイラがデコレータファクトリFの署名をdeclare type PropertyDecorator = (target: Object, propertyKey: string | symbol) => void;と比較し、最終的に割り当て可能になることです。 これらの問題を確実にキャッチするには、ここでより強力なチェックが必要だと思います。 これを修正するために＃3246をログに記録しました。 私はあなたが正しいことをしていると信じています、そしてコンパイラはデコレータファクトリの無効な使用を捕らえるはずです。

@mhegazyなぜこれが当てはまるのか@Fと@F()同等にすることを妨げるユースケースがいくつかあります。 、そのうちの1つだけに、外部ファクトリ関数の呼び出しも含まれていますか？ これは間違いなく非常に驚くべき動作であり、APIコンシューマーの観点からデコレーターを呼び出す方法が2つある必要がある理由がわからないため、ここでは驚き最小の原則に違反しているようです。

JSの観点からは違いがありますが（1つはF関数の参照を渡し、もう1つは関数を実行してから、その結果の参照をデコレータとして渡します）、私は違います。 @Fとして渡されたデコレータを、空のパラメータリストを持つものとしてファクトリに暗黙的に一致（および呼び出し）させることができない理由を理解していますか？

コンパイラには、それがファクトリであるかデコレータであるかを知る方法がありません。 この署名がある場合：

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

これはデコレータですか、それともファクトリですか、空の引数で呼び出す必要がありますか？

コンパイラーができることのほとんどは、署名をいずれかの方法で呼び出すときに署名が一致することを確認し、一致しない場合はエラーを出すことです。

@rbucktonには、デコレータがファクトリとして使用されていない場合にフラグを立てる＃3246の修正がありますので、ご

@mhegazy 、私が言っているのは、デコレータ（つまり、 @Fまたは@F() ）の使用は、常に適切なデコレータタイプを返すファクトリ関数Fの呼び出しである必要があるということです。 カプセル化ファクトリがなければ、デコレータのトップレベルの表現はありません。

言い換えれば、Fの署名は常に次のとおりです。

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

または同等のもの。

次に、呼び出し@Fは、コンパイラーによって@F()と同等になります。 @Fと@F()両方の署名が何らかの形でファクトリ署名と一致する必要があるため、これにより呼び出しの混乱の問題が解決されます。 デコレータを呼び出す方法は1つだけです。

次の場合：

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;

それらは同じことをしますが、私はそれらを異なって宣言しなければなりません！ ただし、Fを双方向に存在できるように宣言することは非常に面倒であり、一貫したパラメーターとドキュメントを作成することは不可能です。 デコレータがファクトリを使用する必要があるかどうかを選択しており、APIコンシューマは、それを使用するために事前にこの区別を知っている必要があります。

@Tharaxisデコレータとして使用されるFを提供するライブラリを探している場合、 @Fと@F()はまったく異なるものになると絶対に期待しています。 CとC()が異なるものであると期待するのと同じように、最初は値を参照し、2番目は値を呼び出します。 @Fはデコレータを適用し、 @F()はデコレータを作成する関数を呼び出します。 それらは同じ操作ではなく、同じ操作であってはなりません。

@DavidSoutherこれが当てはまらない、または当てはまらない正当な理由はありますか？ @Fと@F()呼び出しには機能的な違いはありませんが、それらの定義方法と文書化方法にはかなり大きな違いがあり、呼び出しがさらに複雑になり、不要になるはずです。

私の提案は、デコレータを定義する必要がないため、2つの方法があってはならず、デコレータを複数の方法で定義する必要がないということです。

@Fと@F（）の呼び出しの間に機能的な違いはありません

これが論争の要点だと思います。 私はこれが真実だとは思いません。 Fは関数への参照であり、F（）は空の引数セット（つまりF.call(this, []) ）で呼び出されたときのFの戻り値への参照です。 これらは機能的にも概念的にも異なる2つのものです。

@Tharaxis @Fと@F()は別物です。 それらの使用方法、文書化の方法、および絶対に必要な呼び出しの違いがあります。

別の方法で質問させてください。なぜすべてのデコレータ関数をファクトリにする必要があるのでしょうか。 あなたの提案を使用すると、単純なデコレータを持つことは不可能です。

@mhegazyは、後者のオプション（ @F() ）が、分離された（および複製された）デコレータ関数の作成と@F呼び出しを通じて、機能クロージャと追加のオーバーヘッドの生成をもたらすことを認めます。基本的に、共有デコレータ関数参照に対して実行されます。クロージャによる分離は「より安全」で一貫性があり、驚きの可能性が低くなります。

@DavidSoutherあなたの質問は、単純なデコレータとして何を定義するかによって異なります。 次の形式の単純なデコレータを持つことを妨げるものはありません。

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

これは「単純な構文」よりもわずか2行多く、使用可能なデコレータ呼び出しが何であるかをより明確に定義しているため、これは非常に低侵襲であることがわかります。 さらに、デコレータを定義する方法は1つしかないため（一貫性の値を軽視しないでください）、「単純な構文」と比較して、これを作成するのにおそらくさらに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;

これらのうちの1つは他とは異なります。 @Fの使用は、額面どおりに機能するはずですが、機能しません。 私がFの基礎となる宣言がどのように見えるかを知らないが、代わりにFが存在し、オプションの引数のセットを取ることができることを知っている人のふりをすることを覚えておいてください。 私が@F間違える可能性は、現在のメカニズムでは簡単ではありません。 これは、開発者/ドキュメンテーションに大きな責任を負わせ、消費者が@Fが機能しないことを認識していることを確認します（ただし、 @Cは何らかの形で「異なる」ため、機能する可能性があります）。

消費者が心配する必要のない「1つのサイズですべてに対応する」デコレータが必要な場合は、次のような恐ろしいことを行う必要があります。

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

これは率直に言って恐ろしいことです。 さらに、デコレータFに対する貴重なパラメータのインテリセンスはすべて失われます。これは、一般化する必要があるためです。

デコレータを定義して文書化するのが簡単で一貫していると言われることがたくさんあります。 私たちのコードを消費するすべての人が、そのコードの作成者である私たちと同じ知識や理解を持っていると思い込まないでください。

@Tharaxisデコレータのデザインの早い段階でこれについて考えましたが、あなたの具体的なポイントは理解しています。 @mhegazyと@DavidSoutherがこのスレッドで前述したように、この動作はJavaScriptの関数の標準的な動作と一致しています。

デコレータとデコレータファクトリの両方として機能できる関数を作成しようとすると、多少複雑になる可能性があることは間違いありません。 ただし、一般的には、常にデコレータファクトリを使用するベストプラクティスを採用し、このプラクティスが確実に採用されるようにリンターにルールを提供する方がよい場合があります。

また、デコレータのタイプチェックの不整合に関する以前のポイントに対処するために、PR＃3249を提出しました。

こんにちは@rbuckton 、

私は@Tharaxisによって言及されたデコレータのそれほど精通していないユーザーの1人です...

私が持っている質問は、デコレータが関数と一致している必要があるかどうかだと思います。 つまり、関数の場合、this.fとthis.f（）を返すことは、値が必要な場合もあれば、値を生成するものが必要な場合もあるため、完全に理にかなっています。

デコレータの場合、言語機能レベルではそれほど明確ではないようです。 デコレータ@Fを適用したいだけで、ファクトリメソッドとして実装されているのか静的メソッドとして実装されているのかを知りたくありません。 それは、デコレータが持っている機能を失う場合を除いてです。

上記が誤った情報や無知である場合は、申し訳ありませんが、私はJavaScriptの世界では比較的新しいです。

ありがとう＆乾杯

また、その質問をする必要があります-「関数を使用して定義されているため」以外にそうする本当の理由がない場合にのみ、関数_if_と構文上のパリティを維持することは理にかなっていますか？ デコレータは、デコレータを使用して定義されるだけの関数とはまったく関係のない機能だと思います。

現在、 @Fと@F()が同一ではないという事実により、次の問題が発生します。

• @Fと@F()の違いと、なぜこれが機能するのか、なぜ機能しないのかを理解する必要がある開発者（および、 @Fと@F()を使用する必要性） declare function A(params?: any): ParameterDecoratorとdeclare function B(target, name)想像してください、 @Aは機能しませんが、 @A()は機能し、 @Bは機能しますが、 @B()は機能しません。それでも、認知的には同じものであり、引数のないデコレータのアプリケーションです）。
• コードレベルから問題を解決するには、デコレータの呼び出し構文を適切に文書化する機能を削除する、厄介な回避策が必要です。
• 'rawデコレータ'（ @F ）を作成し、いくつかのパラメータを追加したい場合（ただし、下位互換性のためにオプションにします）、リファクタリングは少し手間がかかります。 現在の方法では、適用されるすべての@Fを@F()リファクタリングする必要があります（コード内の一部にはアクセスできない場合があります）が、暗黙的な呼び出しにより、動作を維持し、コードを変更します。

@Tharaxis @Fと@F()の違いは、消費者の認知的負担が大きい可能性があることを理解しています。 ただし、発行されたコード、つまり動作を変更して、2つが同等に動作するように要求しているようです。 2つの形式が同じように扱われる可能性は非常に低いため、これはデコレータに関するES7の提案と矛盾する可能性があります。 これが発散につながるのは良くないでしょう。

もう1つのポイントは、ここでの混乱は、関数をコールバックとして渡すことと関数を呼び出すことの間の混乱に似ているということです。 あなたがこれを持っていたなら

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

ユーザーは混乱して呼び出すことがありますtakesCallback(callbackFactory)起動せずにcallbackFactory 。 これは、デコレータで指摘した混乱とまったく同じですが、言語がこれら2つの形式を正規化して同じことを行うと、表現度が低下します。 区別が重要な場合があり、維持する必要があります。 これがデコレータにも一般的に当てはまるかどうかはわかりませんが、理論的には確かに当てはまります。

@JsonFreeman私はあなたの議論を本当に

関数に関するあなたの例としては、実際には完全に異なる構造である（そしてそうあるべきである）ときに、関数をデコレータと混同しているように見えます。 JavaScriptで関数を操作しているとき、関数がどのように使用されているかを理解し、関数参照と関数呼び出しの違いを理解しています（そして、どちらか一方を使用したい場合）-そして何かを説明するとき機能として、それがどのような使用法を持っているかについて混乱はありません。 デコレータは関数ではなく、関数の動作を継承するべきではありません。 関数は、デコレータを構築するための方法にすぎません。 これは、クラスが関数であると言っているようなものですが、そうではありません。関数は、ES6より前のクラスを説明する方法にすぎません。これ以上、明白なメソッドが利用できなかったためです。 クラスは関数のプロパティを引き受けません。関数のようなクラスを呼び出すことはできませんが、ES6より前の関数を使用してクラスを宣言します。

とにかく、私はこの問題についての私の議論のポイントを使い果たしたと感じています。 選択を回避する必要があります。 私自身のコードでは、一貫性を保つために常にファクトリを使用します。 デコレータを文字通り関数として扱うことは、将来的に多くのフラストレーションを引き起こす可能性があると私は今でも信じていますが、それは私だけです。

@mhegazyこれは、 @ jonathandturnerデコレータリポジトリで取り上げたのと同じ問題です： https ：

@Tharaxis 、私はあなたの最初の点に同意します。 ES7の提案が私たちが何かをうまく設計することを妨げるべきではないと私は思います、そして私たちの設計は確かにES7の前兆の1つです。

「デコレータは関数の引数ではない」については、私が誤解しない限り、デコレータ自体については説明していません。デコレータファクトリについて説明しています。 そして、デコレータと関数の違いに関係なく、デコレータ_factories_は実際には単なる関数だと思います。 そして、通常の関数であるデコレータファクトリへの呼び出しを自動的に生成するようコンパイラに要求しているようです。 それが起こった場合、プログラマーがデコレーターファクトリーとデコレーターを区別する方法はありません。

また、デコレータを関数として扱うことの良い点は、消費者がデコレータとして、または単に適切と思われるように呼び出すことで、デコレータを適用できることです。

@JsonFreeman引数は、デコレータの記述と呼び出しの両方を行う2つの方法がある現在の状況を中心に展開します。1つはファクトリ関数を使用し、もう1つは「raw」関数として（ファクトリの場合はファクトリ呼び出しの結果です）。 ）、そして質問は「ただ一つの方法があるべきではなく、工場をそのようにするべきである」ということでした。

私が求めているのは、はいです。コンパイラに@Fを@F()呼び出しと同等のものに変換させ、型チェックに0 ... nパラメータの引数リストを要求させることはできません。括弧なしの構文。 おそらく、「...プログラマがデコレータファクトリとデコレータを区別する方法はないでしょう...」の意味を詳しく説明することができます。区別するのは非常に簡単だと思うからです。 デコレータは常にファクトリからの応答であり、ファクトリの名前はデコレータの名前です...それほど難しいことではありませんか、それとも私は誤解していますか？

消費者がデコレータを適用できるようにすることについての最後のポイントについては、すべてのデコレータがファクトリを使用することが十分に説明されている場合、自分でデコレータを呼び出すのは非常に簡単です。 <decorator name>(target, name)と比較して<decorator name>(<argument list>)(target, name)実行するだけです。例として<decorator name>(target, name) 。 工場の使用を義務付けることは前者の例が常に機能することを意味しますが、義務付けない場合は後者の例が機能しない場合があり、デコレータの実装方法に完全に依存することに注意してください-頭痛が起こるのを待っています。

指摘する必要があると思います。関数を使用するデコレータに問題はありませんが、同じことを2つの方法で記述すると、一貫性の問題が発生するという問題があります。 特に、これら2つの方法が、呼び出し方法が異なる必要があることを意味する場合は特にそうです。 これは、リファクタリングから言語の一貫性まですべてを妨げる格差です。

いくつかの投稿で説明したリファクタリングの問題は、現在の方法を検査する必要がある理由としては十分すぎるはずです。

みなさん、こんにちは。

次の場合は、現在の提案に満足しています。
a）宇宙はそれを義務付けています。
b）状況が異なると、デコレータは重要な機能を失います。

後者はもちろん価値判断であり、その答えはあなたが開発者のタイプ（つまり一般ユーザー/エキスパートユーザーなど）にある程度依存します。 私は前者のカテゴリーに属しており、通常、複数の言語とフレームワークに薄く分散しています。 したがって、私にとって「重要な機能」には、デコレータを2つの異なる方法で記述できる柔軟性は含まれません。 すべてのトレードオフの例は、それらが存在する場合は素晴らしいでしょう。

理想的には、 @ Fと@F（）がデコレ​​ータの実装方法に関係なく一貫していれば素晴らしいのですが、そうでない場合は、草の中のすくいを避けるよりも、デコレータを作成するときにファクトリを使用するように制限されたいと思います。私がそれらを使用しているときはいつでも。

ありがとう＆乾杯

このリクエストは、デコレータファクトリがデコレータを使用するための標準的な方法であるという考えに基づいているようですが、これによってユーザーが生のデコレータを定義して使用する方法がわかりません。 デコレータFを定義し、アプリケーション@Fが@F()として扱われる場合、F自体ではなく、Fを呼び出した結果がデコレータとして使用されます。 誰かがデコレータファクトリの代わりに生のデコレータを適用しようとすると、どこかでエラーが発生することを示唆していますか？

このアイデアは、デコレータとデコレータファクトリの自然な構成性を逆転させるように感じます。 デコレータは間違いなくここの原始的な構成のように感じます。デコレータファクトリはデコレータの上に構築された抽象化レイヤーです。 それらは単なるパターンであり、それ以上のものではありません。 代わりに、デコレータファクトリが標準的なもの、つまりプリミティブになった場合、人々は、引数をとらずにフラットなデコレータを返すデコレータファクトリの束を定義します。 これは非常にばかげていると感じ始め、基本的と見なされるものとより複雑と見なされるものの自然な直感を逆転させます。

デコレータに関して私が非常に警戒していることの1つは、過剰な魔法です。 コードが何をしているのかわからないときは個人的に緊張します。コンパイラーがプログラマーが書かなかった呼び出しを密かに追加していると、それはあまりにもブードゥーのように感じます。

こんにちは@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) {...}

とにかく、そのようなアプローチが理にかなっていることがわかった場合、注釈が関数の目的を文書化するという利点があります。 つまり、それは飾る。

乾杯

良い肉汁、デコレータの定義に役立つデコレータ、Typeceptionの深刻なケース。

@JsonFreemanゼロパラメータ関数を使用することが、代わりに多数の（ターゲット、名前）関数を使用するよりも必ずしも醜いものであるかどうかは

もう1つのオプションは、 @Fと呼ばれるデコレータが、ClassDecorator、MethodDecorator、PropertyDecorator、ParameterDecoratorのパターン、またはClassDecorator、MethodDecorator、PropertyDecoratorを返す0..nargファクトリ関数のいずれかに一致できるようにすることです。またはParameterDecorator。 ただし、その実装は他のエラーを引き起こし（2つの競合する関数がある場合、どちらが最も一致すると見なされますか？）、コンパイラー内に過度の複雑さを追加するだけだと思います。 @F呼び出しを@F()変換するだけで、より簡単な解決策になり、前述のさまざまな問題を解決できます。

申し訳ありませんが、明確にするために、私はあなたの解決策が複雑であるとは主張していませんでした。 デコレータを適用する前に自動的に呼び出すことは不透明であることを意味しました。 挿入された呼び出しはユーザーには見えず、多くのユーザーがそれを期待していないように感じます。

現在の状況も複雑ではないと思います。 ご指摘のとおり、ライブラリの作成者は、その機能がデコレータとして適用されることを意図しているかどうかについて、漠然としているか、意地悪な態度をとることができます。 私があなたに与えること。 しかし、優れたライブラリはそれを明らかにします。

提案するスキームでは、呼び出しを自動的に行う場合、識別子だけでなく任意のデコレータ式を使用するとどうなりますか？ それも呼び出されますか？

特に文書化されていない限り、暗黙の呼び出しは驚くべきものになる可能性がありますが、C＃属性などの概念を使用していない人にのみ同意します。

任意のデコレータ式の意味について詳しく教えてください。

良い肉汁、デコレータの定義に役立つデコレータ、Typeceptionの深刻なケース。

フェアコール。 週末の午後遅くに、よく考えられていないコメントをするのにぴったりです。 学んだ教訓。 Internet.undo（）。

私のポイントは、一貫した呼び出しサイトの構文でファクトリの使用が義務付けられていることが判明した場合、私はそれに満足しているということです。 ボイラープレートを取り外すためのデコレータを作成することは間違いありません。 繰り返しますが、デコレータを使用する場合の繰り返しの痛みよりも、デコレータを作成するときの少しの痛みの方が好きです（現時点では潜在的な痛みがありますが）。 他の人は同意しません。

APIの機能強化にも問題はありませんか？ ファクトリなしで作成されたデコレータには、後でオプションのパラメータを追加することはできないため、将来的には@Fと@F2()を予測します。

また、 fとf()を使用すると、このシナリオが発生することはわかりません。これらは、消費側で異なるユースケースです。 デコレータの場合、私は常にターゲットにデコレータをその場で適用/呼び出しており、バックグラウンドでメソッドの呼び出しが常に行われています。

しかし、私にとってこれの核心は使いやすさの問題です。デコレータを適用するとき、著者がそれをどのように実装したかを調べるためにグーグルで検索する必要はありません。パッケージではなく、動作に関心があります。

乾杯

要約する最後のメモです。それから私は静かにしておきます。 要するに、これは私にとって本当に単なるインタラクションデザインの問題です。 私はデコレータが外側からデザインされているのを見たいと思っています。その逆ではありません。

UI / UXの人として、私はこれをかなり頻繁に見ます。 私は、ユーザーを傷つけるUIソリューションを提案した才能のある開発者と協力してきました（1つの例は、トランザクションの複雑さを解決するための2つの保存ボタンでした-これも賢くて優秀な人間です）。 複雑な実装の詳細ロジックにひざまずくと、知っていることを忘れて、平均的なユーザーの目を通して見るのは難しいと思います。

さて、平均として私がまったく間違っている場合、または複雑さが現在の設計を義務付けている場合、すべてが良い場合、私は頭を悩ませて学ぶ必要があります。

乾杯

デコレータが識別子ではなく、他の式である場合、自動的に呼び出しますか？たとえば、デコレータであるとしましょう。 フォールバック関数式と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;
}

それらはスコープの順序に従うので、すべてのプロパティ/メソッドが最初に宣言の順序で、次にクラスの順序になります。 すなわち、B、C、D、E、F、A。

生成されたコードはここで確認でき

現在、パラメータのプロパティを装飾することはできないようです。 それらはサポートできますか？

パラメータプロパティは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に詳細があるかもしれません。

デコレータが装飾されている結果のタイプを装飾されているタイプから変更できないのはなぜですか？

たとえば、MethodDecoratorは、次のように提案することもできます。

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はここでは有効な議論ではありません、私見。 まず、JavaScriptのデコレータはクラス/フィールドタイプを変更できるため、TSとJSの間に互換性の問題はありません。 次に、デコレータは静的に適用されます。TSコンパイラは、定義サイトで元のフィールドタイプと装飾されたフィールドタイプについて推論できます。

@HerringtonDarkholmeこれは別の提案で追跡する必要があると思います。 主な理由は、コンパイラが型について推論する方法が宣言によるものであるということです。 型が宣言されると、それを変更することはできません。 ミックスにタイプミューテーターを追加するということは、毛むくじゃらになる可能性のある宣言を解決しているので、これらを解決する必要があることを意味します。

@mhegazyでは、これを意図的な設計ではなく、実装を容易にするための妥協案として理解できますか？

この提案によると、デコレータは、宣言型構文を維持しながら、設計時にコードを実行する機能を復元します。 したがって、次のコードは次のようになります。
将来のJavaScriptでは有効ですが、今日のTypeScriptでは無効です（ただし、これはいつかTSで受け入れられる可能性がありますよね？）。

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タイピングのような似たような話ではないことを確認したいと思います。

現在のチェックでは、ターゲットに割り当て可能なデコレータから何かを返す必要があります。 欠落している部分は、タイプへの追加をキャプチャしていないことです。 どうすればいいのかわからないと思いますが、あまり考えていません。 ですから、それは公正な提案だと思いますが、それを実装するためのコストは非常に高いかもしれません。

理想的には、デコレータによって返されるタイプはターゲットと同じである必要があると思います。 割り当てのソース位置とターゲット位置のどちらで装飾タイプを使用するかはわかりません。

デコレータのリターンタイプとターゲットをマージする必要があると思いますが、ミックスインのようなものです。

いくつかの追加機能のアイデア。 TypeScriptコンパイラの出力はJavaScriptであるため、 XtendなどのJava用の同様の言語がいくつかあります。

このプロジェクトに関するいくつかの興味深いアイデアについて学ぶことができます。 アクティブなアノテーションを探す「アクティブなアノテーションにより、開発者はライブラリを介してXtendソースコードからJavaコードへの変換プロセスに参加できます」

デコレータを介してTypeScript出力を制御することは本当に素晴らしい機能です！

インターフェイスのデコレータが可能である必要があります。

@shumy問題は、インターフェイスが実行時に存在せず、デコレータが純粋に実行時に実行されることです。

戻り値に関して、プロパティデコレータをメソッドデコレータとは異なる方法で扱う理由はありますか？ （バベルはしません）。

つまり、デコレータを介してプロパティの機能を定義する場合は、次のようにする必要があります。

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

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

Babelでは記述子を返す必要があります。

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

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

これにより、Babelから使用されるライブラリの一部であるTypeScriptでデコレータを作成することが困難になります。

プロパティデコレータはメソッドデコレータと同じように扱われ、デコレータの戻り値はObject.defineProperty介して適用されることを提案します。 これにより、メソッドと同じように、1つのプロパティで複数のデコレータを使用することもできます。

今のところ（Babel互換性のための）回避策は、プロパティの設定に加えてデコレータから記述子を返すことですが、それは不必要に無駄に思えます：

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

@mhegazy上記の私のコメントについて何か洞察がありますか？

@sccolbert TypeScriptでは、記述子で指定された「値」がインスタンスではなくプロトタイプに設定されるため、実行時に問題が発生する可能性があるため、データプロパティのデコレータにプロパティ記述子を使用できないようにしました。 。 上記の例は通常問題にはなりませんが、次のことを考慮してください。

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 (!)

コンストラクター中に評価される記述子の「初期化子」プロパティをサポートするESの将来のバージョンの提案があります。 これにより、値をプロトタイプに設定するか、インスタンスごとに割り当てるかを制御できます。

今のところ、コメントの例のように、 Object.defineProperty直接呼び出すことで、この制限を回避できます。 今後もこの制限を緩和するかどうかを検討していきます。

@rbucktonありがとう！ あなたたちは同じセマンティクスに収束するためにバベルと話し合っていますか？ それが一番大事だと思います。

特定のインスタンスの値を指定するためにデコレータを使用すると便利なのはなぜですか？ それがプロパティ初期化子の目的ではありませんか？

私のユースケースは、例よりも複雑です。 私は実際にデコレータを使用して、プロパティのthisコンテキストにバインドされたオブジェクトを返すゲッターを定義しているので、そのオブジェクトのメソッドは、それが定義されたインスタンスにアクセスできます。

これは、Pythonで記述子プロトコルをエミュレートするfoo （つまりfoo.bar ）を介してクラスFoo定義されたメソッドbarにアクセスすると、 __get__返す関数の方法BoundMethod 。 そのオブジェクトが呼び出されると、基になる関数が最初の引数としてself （この場合はfoo ）で呼び出されます。 Javascriptが私たちが周りに合格しなければならない理由である、この概念を持っていませんthisArgして呼び出すfunction.bindすべての場所で。

私の場合、メソッドを定義しているのではなく、タイプセーフなシグナルを定義しています。 デコレータは次のとおりです。
https://github.com/phosphorjs/phosphor-signaling/blob/1.0.1/src/index.ts#L144

プロパティにアクセスすると、所有者のthisコンテキストにバインドされたISignal実装が返されます。 これにより、シグナルは、それが定義されたインスタンスを参照できるようになります。
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では使用できないプロパティ記述子を使用します
9月4日 2015 2:03 PM、「Koloto」 [email protected]écrit ：

@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

@DavidSoutherブラウザはまだプロキシをサポートしていません:(

@cybrownはい、メソッドとアクセサーのプロパティ記述子を使用します。 プレーンプロパティ（アクセサのないフィールド）でのみテストしました。 ただし、ES3ではプロパティ（アクセサなし）とクラスに対してデコレータを許可できるようです。 それは役に立ちます。

また、ES3をターゲットにする場合、メソッドに偽のプロパティ記述子を使用できます。 { writable: true, enumerable: true, configurable: true }ようなもの。 そのため、ES3をサポートしない理由はわかりません。

@sccolbertなるほど。 それは理にかなっている。 ちなみに、TypeScriptは、関数とメソッドの_this_タイピングの改善に取り組んでいます。 それがここで何か助けになるのだろうか。 タイピングはあなたにとって問題ではないと思いますが、それは実行時のセマンティクスです。

@JsonFreeman改善された_this_タイピングは、他のいくつかのユースケースに興味をそそられるように聞こえます。 それについてもっと情報がありますか？

_this_タイピングに関する最も発展した議論は＃3694にあると思います。

乾杯！

エラーTS1207：デコレータを同じ名前の複数のget / setアクセサに適用することはできません。

<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への1回の呼び出しで定義されます。 これはむしろjsの癖であり、setとgetの宣言は別々ですが、実際には同じプロパティ宣言です。 コンパイラのエラーチェックは、ユーザーが個別に考えるときにユーザーに警告することです。 デコレータは、プロパティ記述子に1回だけ適用されます。

コンパイラーは同じ名前のgetとsetを感知し、単一のObject.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％確実になるまで、またはECMA-262内で少なくともステージ2以上の受け入れが可能なデコレータ提案の一部である十分に文書化されたアプローチが得られるまで、簡単に気付かれず、実行時に予期しない動作を引き起こす可能性のある重大な変更を導入することなく、後日その制限を緩和できるため、ここではより制限的でエラーになります。

@rbuckton詳細な説明ありがとうございます
TSチームお疲れ様でした!! ^^ d

このためのドキュメントはどこにありますか？ 実装コミットをリンクすることに気をつけますか？

ありがとう。

@mhegazy最新バージョンの仕様の実装に関する状況はどうなっていますか。 そこにいくつかの変更があることを理解しています。

この問題は、提案の元のバージョンを追跡しました。 これが完了したので、この問題をクローズします。 仕様の更新については、新しい問題をログに記録し、すべての重大な変更の概要を説明します。 提案は、私たちがそれに飛びつく準備ができている場所にあるとは思いません。 新しい提案については、 @ wycatsと緊密に

@omeid 、ドキュメントはhttps://github.com/Microsoft/TypeScript-Handbook/blob/master/pages/Decorators.mdにあります。

@mhegazy更新していただきありがとうございます。 常に情報を入手したいです。 仕様更新の新しい問題を作成するときは、ここにリンクしてください。通知を受けてフォローできます。 Aureliaコミュニティはデコレータを多用しているため、アップデート時にTypeScriptとBabelの両方と同期する必要があります。 繰り返しになりますが、TSチームが行っている素晴らしい仕事に感謝します！

もちろん機能装飾は必要です。
コード内の他のオブジェクトを装飾する計画もありますか？