13

このビデオ(約 31 分) で、Crockford は (ECMAScript 委員会を代表して)使用しないことObject.getPrototypeOfを推奨していると述べています。彼の説明によると、それは平均的な開発者向けではなく、Caja のようなものを対象としておりObject、アクセスできないように削除される可能性があります。

Crockford 氏は、JS の使用方法に関する彼の見解にかなりのこだわりを持っている場合があります (私たち全員ではないでしょうか?) ので、これが本当に ES 委員会の完全な推奨事項なのか、それとも Crockford 氏の個人的な意見の 1 つにすぎないのか疑問に思っています。の使用を警告する公式声明を読んだ人はいますObject.getPrototypeOfか? それは私にとって本当に残念なことのように聞こえます :( が、MDN ページにはその使用を警告する情報は見当たりません。

4

1 に答える 1

15

そこでの彼の推論は信じられないほど貧弱です。それ(およびObject.getOwnPropertyNames)は、Cajaなどを使用するために単に追加されたものではありません。また、Cajaは単にそれらを削除しません!CajaはObject.getOwnPropertyNames実装するためにインターセプトしWeakMap私のシムも同様です)、私が知る限り、getPrototypeOfを変更しません。Object.getPrototypeOf(o)IE以外のすべてのブラウザに実装されているものと同じであり、o.__proto__(現在)オフにすることはできないため、実際にはとにかく意味がありません。つまり、Object.getPrototypeOfから削除しても効果があるのはIE9とIE10だけです。

私が彼が与えると思った理由は、それらの関数のいくつかは主に「ライブラリ作成者」タイプの使用法での使用を目的としているためです。これは、仕様プロセスに関係する人々によって一般的に信じられている/言われていることであり、正当な主張であると私は信じています。プロパティ記述子/属性およびその他の「メタ」レベルのAPIは、使用が面倒であり、通常、正しく使用するにはより完全な言語の習得が必要な、より高度な機能です。ただし、これでも「使用しない」という包括的な推奨事項にはなりません。しかし、このより正確な主張は、彼の主張でさえありませんでした。

彼が間違った発言をしたビデオについての1つの追加のメモ。彼は、プロパティ属性(列挙可能、構成可能、書き込み可能)は、一度設定すると変更できないと述べました。これは正しくありません。これらは、真実である限り変更できconfigurableます。falseに設定すると、属性は凍結されます(プロパティを削除することもできません)。


編集:調査を行った後、私はこの機能と他のオブジェクト機能に関する元の議論のいくつかを見つけました。私が理解している要約は次のとおりです。

オブジェクトの[[Prototype]]にアクセスできることのセキュリティへの影響について懸念がありました。ただし、これらの懸念はObject.freezeなどを介してより完全かつ適切に対処され、これらの関数がObject.prototypeまたは魔法のようにではなく静的関数(1つの場所で削除可能)としてObjectに存在することにも部分的に対処されています(および理由)歴史的にプロトのようなすべてのオブジェクトにありました。

提起された別の懸念は、カプセル化を破ることでした

確かに、protoまたはgetPrototypeOfは、オブジェクトのカプセル化の障壁を打ち破り、おそらく非表示にすることを目的とした実装の詳細を明らかにします。提案されたgetProperty関数についても同じことが言えます。これは、とりわけ、オブザーバーにgetter/setterプロパティを実装する関数へのアクセスを提供します。一般的に、それは反射の性質です。-AllenWirfs-ブロック

実装の終わりから提起された懸念の1つは、実装の詳細を公開することでした(DOMの多重継承の使用の変更とWebIDLへの移行によって対処されたDOMの動作に起因する懸念がほとんどです)。

一方、オブジェクトのプロトタイプへのリフレクティブアクセスを提供すると、実装がWebを壊さずに中間プロトタイプを導入できなくなるため、互換性に悪影響を及ぼします。数字だけを持ち、後で互換性を持ってより具体的な数字のサブカインドを導入する例を考えてみましょう。-Waldemar Horwat

この懸念は、同じクロスフレームである内部の隠されたプロトタイプについて、スクリプト調整メーリングリストで言及されている別の懸念にも関連しています。この問題は、各フレームが独自のDOMプロトタイプのセットをインスタンス化する必要があることが決定および実装されたES5(およびIE8)の時点でも歴史的です。したがって、この理由でプロトタイプを非表示にすることは、ES5が正式に公開されるまでにはもはや関係がありませんでした。


私が見るコンセンサスは、クロックフォードの説明に従わない。ほとんどの場合、それは彼自身の意見の言い換えにすぎないようです。

要約すると、オブジェクトのプロトタイプへのリフレクティブアクセスを提供しないことは、実際には実際のセキュリティを提供しません。それは、いくつかの有用なタスクを不便にするだけです。 -AllenWirfs-ブロック


私はここで一般的にあなたに同意します、そして反射が「本当の安全」の敵ではないと聞くのは良いことです。 -ブレンダン・アイク

このための出発点は、提案されたECMAScript 3.1静的オブジェクト関数:ユースケースと理論的根拠(TC39でCrockfordと他の人によって書かれた)です。私が引用を引用しているそのフォローアップは、このes-discussスレッドです。具体的には、この投稿この投稿

于 2012-10-04T03:32:38.637 に答える