タグ付けされた質問 「duck-typing」

4
Pythonの許しと許可とダックタイピング
Pythonでは、「許可を求める」(タイプ/条件チェック)よりも「許しを請う」(例外をキャッチする)の方が良いとよく耳にします。Pythonでのダックタイピングの強制に関して、これは try: x = foo.bar except AttributeError: pass else: do(x) より良いか悪い if hasattr(foo, "bar"): do(foo.bar) else: pass パフォーマンス、可読性、「pythonic」、またはその他の重要な要素の面で?


4
多くのアヒル型動的プログラミング言語が、プロトタイプベースのOOPではなくクラスベースのアプローチを使用するのはなぜですか?
非常に多くの動的プログラミング言語にはダックタイピングの機能があり、クラスやインスタンスのメソッドをいつでも開いて変更できるため(RubyやPythonなど)、... 質問1)動的言語のクラスの必要性は何ですか?プロトタイプ言語ではなくオブジェクトを使用するのではなく、クラスを何らかの「テンプレート」として使用するように言語が設計されているのはなぜですか? また、JavaScriptはプロトタイプベースですが、CoffeeScript(JavaScriptの拡張バージョン)はクラスベースの方法を選択します。また、Lua(プロトタイプベース)とMoonScript(クラスベース)でも同じです。さらに、ES 6にはクラスがあります。 質問2)特にプロトタイプベースの言語を改善しようとする場合、クラスベースに変更する必要があることを示唆していますか?そうでない場合、なぜそのように設計されているのですか?

6
アヒルは多型のサブセットを入力しています
WIkipediaの多態性から コンピュータサイエンスでは、ポリモーフィズムはプログラミング言語の機能であり、さまざまなデータ型の値を統一されたインターフェイスを使用して処理できます。 ウィキペディアのカモタイピングから オブジェクト指向プログラミング言語を使用したコンピュータープログラミングでは、ダックタイピングは、特定のクラスまたは特定のインターフェイスの実装からの継承ではなく、オブジェクトの現在のメソッドとプロパティのセットが有効なセマンティクスを決定する動的なタイピングのスタイルです。 私の解釈では、アヒルのタイピングに基づいて、オブジェクトのメソッド/プロパティが有効なセマンティクスを決定します。オブジェクトの現在の形状が、保持するインターフェースを決定することを意味します。 ポリモーフィズムから、インターフェイスを維持している限り、複数の異なるデータ型を受け入れる場合、関数はポリモーフィックであると言えます。 したがって、関数が型をダッキングできる場合、複数の異なるデータ型を受け入れ、それらのデータ型に正しいメソッド/プロパティがあり、インターフェースを維持している限り、それらを操作できます。 (インターフェースという用語の使用は、コード構成ではなく、記述的で文書化された構成としての意味です) ダックタイピングとポリモーフィズムの正しい関係は何ですか? 言語がタイプをダッキングできる場合、それは多態性を実行できることを意味しますか?

3
プロパティとメソッドを常にチェックせずに、JavaScriptでダックタイピングを使用するにはどうすればよいですか?
私はjavascriptがダックタイピングを使用することを知っていて、最初はC#のような強く型付けされた言語と比較して多型が簡単になると思った。しかし、現在、引数を取る私の関数には次のようなものが散らばっています。 if(myObj.hasSomeProperty()) または if(myObj.hasSomeMethod()) または if(isNumber(myParam)) 等 これは本当にugいです。私はC#のバックグラウンドを持っていますが、定義済みのインターフェイスの方がはるかに優れていることがわかりました。 私は静的に型付けされた言語で効果的な戦略を誤って適用しようとしていて、javascriptでこれを行うためのいくつかのより良い方法がありますか? 私はただチェックできないことを知っていますが、javascriptランタイムエラーを追跡することは、コード内で実際にエラーが発生している場所で常に発生するとは限らないため、悪夢になります。

1
Pythonでのダックタイピング、データ検証、アサーティブプログラミング
アヒルのタイピングについて: アヒルの型付けは、メソッドと関数の本体の引数の型を常にテストするのではなく、ドキュメント、明確なコード、および正しい使用を確実にするためのテストに依存することによって支援されます。 引数の検証について(EAFP:許可よりも許しを求める方が簡単です)。ここからの適応例: ...それを行うにはよりpythonicと考えられています: def my_method(self, key): try: value = self.a_dict[member] except TypeError: # do something else これは、コードを使用する他のユーザーが実際の辞書やサブクラスを使用する必要がないことを意味します。マッピングインターフェースを実装する任意のオブジェクトを使用できます。 残念ながら、実際にはそれほど簡単ではありません。上記の例のメンバーが整数の場合はどうなりますか?整数は不変です。そのため、それらを辞書のキーとして使用することは完全に合理的です。ただし、シーケンス型オブジェクトのインデックス付けにも使用されます。メンバーが偶然整数の場合、例2ではリストと文字列、および辞書を通過できます。 断定的なプログラミングについて: アサーションは、プログラムの内部状態がプログラマが期待したとおりであることを確認する体系的な方法であり、バグをキャッチすることを目的としています。特に、コードの記述中に行われた誤った仮定や、他のプログラマによるインターフェイスの悪用をキャッチするのに適しています。さらに、プログラマーの想定を明確にすることで、インラインドキュメントとしてある程度の役割を果たすことができます。(「明示的は暗黙的よりも優れています。」) 上記の概念は競合する場合があるため、データの検証をまったく行わないか、強力な検証を行うか、またはアサートを使用するかを選択するときは、次の要因を考慮します。 強力な検証。強力な検証とはApiError、たとえばカスタム例外を発生させることです。関数/メソッドがパブリックAPIの一部である場合は、引数を検証して、予期しないタイプに関する適切なエラーメッセージを表示することをお勧めします。タイプをチェックすることで、のみを使用することを意味するのではなくisinstance、渡されたオブジェクトが必要なインターフェース(ダックタイピング)をサポートするかどうかも確認します。APIをドキュメント化し、予想されるタイプを指定し、ユーザーが関数を予期しない方法で使用する可能性がある場合、想定を確認すると安全です。私は通常使用isinstanceし、後で他のタイプやアヒルをサポートしたい場合は、検証ロジックを変更します。 断定的なプログラミング。私のコードが新しい場合、私はアサートをたくさん使います。これに関するあなたのアドバイスは何ですか?後でコードからアサーションを削除しますか? 私の関数/メソッドがAPIの一部ではないが、自分で記述、調査、テストしていない他のコードに引数の一部を渡す場合、呼び出されたインターフェイスに従って多くのアサーションを実行します。これの背後にある私のロジック-私のコードでよりよく失敗し、スタックトレースのどこかで10レベル深く、理解できないエラーが発生するため、多くのデバッグを行い、とにかくアサートをコードに追加する必要があります。 型/値検証をいつ使用するべきか、または使用しないべきかについてのコメントとアドバイスは断言しますか?質問の構成が最適ではないため申し訳ありません。 たとえばCustomer、SQLAlchemy宣言モデルである次の関数を考えてみます。 def add_customer(self, customer): """Save new customer into the database. @param customer: Customer instance, whose id is None @return: merged into global session customer …

1
暗黙的インターフェイスと明示的インターフェイス
コンパイル時のポリモーフィズムと実行時のポリモーフィズムの実際の制限を理解していると思います。しかし、明示的なインターフェイス(実行時の多態性、つまり仮想関数とポインタ/参照)と暗黙的なインターフェイス(コンパイル時の多態性、つまりテンプレート)の概念的な違いは何ですか。 私の考えでは、同じ明示的インターフェースを提供する2つのオブジェクトは同じタイプのオブジェクトである(または共通の祖先を持っている)必要がありますが、同じ暗黙的インターフェースを提供する2つのオブジェクトは同じタイプのオブジェクトである必要はありません。両方が提供するインターフェースは、まったく異なる機能を持つことができます。 これについて何か考えはありますか? また、2つのオブジェクトが同じ暗黙のインターフェイスを提供する場合、これらのオブジェクトがそのインターフェイスを宣言する基本オブジェクトから継承しないようにする理由(仮想関数ルックアップテーブルなどの動的ディスパッチが不要であるという技術的な利点以外)それを明示的なインターフェースにしていますか?別の言い方をすると、同じ暗黙のインターフェースを提供する(したがって、サンプルテンプレートクラスの型として使用できる)2つのオブジェクトが、そのインターフェースを明示的にする基本クラスから継承しないようにできますか? 関連する投稿: https://stackoverflow.com/a/7264550/635125 https://stackoverflow.com/a/7264689/635125 https://stackoverflow.com/a/8009872/635125 この質問をより具体的にする例を次に示します。 暗黙的なインターフェース: class Class1 { public: void interfaceFunc(); void otherFunc1(); }; class Class2 { public: void interfaceFunc(); void otherFunc2(); }; template <typename T> class UseClass { public: void run(T & obj) { obj.interfaceFunc(); } }; 明示的なインターフェース: class InterfaceClass { public: virtual void …

3
ダックタイピングなしで動的に型付けされた言語を持つことは可能ですか?[閉まっている]
休業。この質問には、より焦点を当てる必要があります。現在、回答を受け付けていません。 この質問を改善してみませんか?質問を更新して、この投稿を編集するだけで1つの問題に焦点を当てます。 5年前休業。 この質問はここで尋ねられましたが、不十分な回答を得て、問題を明確にしませんでした。私はそれが再びそれを求めることを正当化すると信じています。 動的に型付けされた言語または静的に型付けされた言語のいずれかでダックタイピングができることを理解しています(ただし、C ++のテンプレートなど、これらの例はまれです)。 しかし、ダックタイピングのない動的に型付けされた言語のようなものがあるかどうかはわかりません。 ダックタイピングとは、オブジェクトのタイプが、特定の時点でのオブジェクトの操作と属性に基づいていることを意味します。ダックタイピングを必然的にサポートせずに動的タイピングを行う方法はありますか? たとえば、このPythonコードを見てみましょう。 def func(some_object) some_object.doSomething() something = Toaster() func(something) 動的型付け言語では、オブジェクトの型は実行時にのみ認識されます。そのため、操作(例some_object.doSomething():)を実行しようとすると、ランタイムには選択肢が1つしかありません。これは、some_objectサポートのタイプかどうかをチェックするdoSomething()ことです。これは、正確にダックタイピングと同じです。 だから、ダックタイピングなしで動的に型付けされた言語を持つことは可能ですか?説明してください。
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.