Backbone: メソッドを拡張するためのゲッター/セッターサポートを追加する

person.fullName()と書くのがうまくいかなかったので、それが関数呼び出しであることがわかる理由はありますか？

ゲッターとセッターを使用することは、ほとんどの場合JSの悪い考えであり、バックボーンモデルのコアアイデアの1つに反します。 近いうちにサポートが追加されるとは思えません。

何よりも、これは新しいクラス構文と部分的に一致します。 クラス構文にはプロパティ初期化子がなく、それらの仕様もまだないため、相互運用性が問題になります。

それらは、バックボーンモデルのコアアイデアの1つに反します。

それはどのようなコアアイデアですか？

また、ゲッターは、 model.idAttributeを使用したBackbone.Collectionの既存の問題に対する部分的な解決策です。

さまざまなソリューションでjsperfを作成するために数分を費やしました：
http://jsperf.com/backbone-extend-with-define-property

それはどのようなコアアイデアですか？

オブジェクトのプロパティの設定と取得は透過的で論理的である必要があるという考え。 obj.prop = valは、そのプロパティ値の設定（取得の場合も同様）以外のことは決して行わないことを常に知っておく必要がありますが、関数を使用して、計算されたプロパティや変更イベントなどを処理する必要があります。 これが、そもそもgetおよびsetラッパーメソッドがattributesの周りにある主な理由です。

また、ゲッターは、model.idAttributeを使用したBackbone.Collectionの既存の問題に対する部分的な解決策です。

現在の_.resultラッパーがこれで機能しない理由は何ですか？ idAttributeは、プリミティブまたは関数のいずれかです。 これもmodelIdで修正されています。

申し訳ありませんが、私が話していた問題にリンクする必要がありました： https ://github.com/jashkenas/backbone/issues/3408

私がこれを取り上げているのは、主にBackboneのクラス構文がすでにESクラス構文とほぼ互換性があるためであり、coffeescriptのサポートが追加されたことを考えると、互換性があるのは妥当なようです。

CoffeeScriptは、主に同じ理由でセッターとゲッターをサポートしていません（https://github.com/jashkenas/coffeescript/pull/2902から始まる背景については、そこで問題を調べてください）。 それらは、バックボーンオブジェクトをクラスとしてサポートするための障害となるべきではありません。

申し訳ありませんが、私が話していた問題にリンクする必要がありました：＃3408

思い出させますか？ 私は、接続がすぐにわかるように緊張しています。

さらに、 extendへの変更は、ここではなく、 _.extendで行う必要があります。 ウォントフィックスとして締めくくります。

CoffeeScriptは、主に同じ理由でセッターとゲッターをサポートしていません

私はゲッター/セッターについて話していませんでした。BackboneがCoffeeScriptとの相互運用のために__super__を追加した方法と、同じ方法でES6クラスをサポートすることだけが理にかなっている方法について話していました。

思い出させますか？ 私は、接続がすぐにわかるように緊張しています。

Collection.extend({
  model: function() { return Model }
});
//
collection.modelId(model); // 'id' regardless if that's correct or not.

Collection.extend({
  get model() { return Model }
});
//
collection.modelId(model); // correct for *some* of the common cases.

さらに、拡張する変更は、ここではなく、_。extendで行う必要があります。 ウォントフィックスとして締めくくります。

新しい_.assignメソッドにあるとすれば、それは間違いなくこの変更に適した場所ではありません。 しかし、ここでIMOをサポートする方がはるかに理にかなっています。

また、この問題が解決されて忘れられる前に、BackboneのextendがCoffeeScriptクラスではなくESクラスとの相互運用の問題を抱えていても問題がない理由について説明したいと思います。

IE Tech Previewは、リモートで適切なclassをサポートしている唯一のブラウザーであるため（Traceurと6to5でさえextendsはまだ変換されていません）、これから離れています。必要。 それはさておき、Backboneは、そもそも優れたアイデアではない機能をサポートするためだけに、下位互換性を壊すために邪魔になることはありません。

Traceurと6to5でさえまだextends変換していません

どちらも実際には機能しますが、広くサポートされている静的プロパティの__proto__のサポートが必要です。

また、バックワードの理由はありません。互換性を破る必要があります。可能な場合Object.setPrototypeOfを選択的に使用すると、互換性をさらに高速化できます。

@thejameskyleこれを問題ではなくPRに変えたいですか？ 一見の価値があります。

確かに、私はそれをします

途中ですか？ あなたはそれについての要点か何かを持っていますか？ 撮りたいのですが。