0

次に、より完全な質問は、「Javascript エンジンが (一般的なエンジンごとに) わかっている場合、これらの考慮事項はどのように影響を受けるか」ということだと思います。

TheConstructorFunction.prototype.constructor = TheConstructorFunction私が「コミュニティ」に尋ねる必要があると思う理由は、Node.js のようなものを作成するStrongloopのような人が、util.inherits のようなコードを書いているからです。設定中:

ctor.prototype = Object.create(superCtor.prototype, {
    constructor: {
        value: ctor,
        enumerable: false,
        writable: true,
        configurable: true
    }
});

これは私には非効率に思えますが、このようなコードの作成者とは対照的に、私は 3 年間、より優れた Javascript を作成するために努力してきました。これが効率的である、または効率的でない理由についての説明はありますか?

1 つの回答は、サブクラスの操作はまれであるため、util.inherits は非効率的ではないと述べています。しかし、一部のライブラリは、ビルドからテスト結果の観察までの間に発生する数百、数千のサブクラス操作を処理することを考慮すると、Node.js が内部で util.inherits を使用すると、そのコンシューマの開発時間に影響します。このレベルでは効率が重要であり、util.inherits が内部で使用されていないことを願っています。util.inherits の目的すら理解できません。なぜそれを持っているのですか？複利の非効率性を助長していると思います。 require('util').inherits(C1,C2);はほとんど同義語でありC1.prototype=Object.create(C2.prototype); C1.prototype.constructor=C1; 、消費者を誘惑することだけを目的としている場合よりも遅い可能性があります。大きなライブラリはNode.jsの効率に依存するため、これらのプロがその関数を内部で使用しているかどうかが私の懸念です。作りに関しては.constructor列挙不可能...その「列挙可能性」が問題になるケースはまれであり、消費者に任せるべきだと思いますが、内部操作がutil.inheritsに依存している場合、これは実際には消費者に任せられていません。

4

2 に答える 2

1

これは私には非効率に思えます

いいえ、ここでは効率は問題ではありません。サブクラス化はまれな操作であり、コードが単純な代入よりも遅くなる場合でも (ほとんどの場合、大きな違いはありません)、パフォーマンスには影響しません。

utils.inherit特にどこでも使用されるようなライブラリ関数にとって重要なのは、正しさです。では、なぜプロパティ属性を使用するのでしょうか。ネイティブに作成され、したがって一般的に期待されるオブジェクト.constructorの標準であるように、列挙不可にすること。.prototype

ここで速度もメモリも考慮する必要がないことを考えると、期待どおりの最適化はここでは行われません。

于 2016-09-29T18:59:41.370 に答える