問題タブ [duck-typing]

私は、Groovy についてさらに調査し、実験を行っており、Java では実行できない/実行できないことを Groovy で実装することの長所と短所に頭を悩ませようとしています。私は静的で強く型付けされた言語に深く浸っているので、動的プログラミングはまだ概念にすぎません。

Groovy はダックタイプを実行できる機能を提供してくれますが、その価値はよくわかりません。ダックタイピングは静的タイピングよりも生産性が高いのはなぜですか? コードの利点を理解するために、コードの練習でどのようなことを行うことができますか?

Groovy を念頭に置いてこの質問をしますが、必ずしも Groovy の質問ではないことを理解しているので、すべてのコード キャンプからの回答を歓迎します。

Java のような静的言語では、インターフェイスが必要です。そうしないと、型システムによって特定のことができなくなるからです。しかし、PHP や Python のような動的言語では、ダックタイピングを利用するだけです。

PHP はインターフェースをサポートしています。Ruby と Python にはそれらがありません。ですから、それらがなくても幸せに暮らせることは明らかです。

私は主に PHP で仕事をしてきましたが、インターフェイスを定義する機能を実際に利用したことはありません。特定の共通インターフェースを実装するための一連のクラスが必要な場合は、それをドキュメントに記述します。

それで、あなたはどう思いますか？動的言語でインターフェイスをまったく使用しないほうがよいのではないでしょうか?

私は何人かの Python プログラマーがかなり一貫して次のスタイルを使用しているのを見てきました (スタイル 1 と呼びます):

このスタイルをサポートするために、「明示的は暗黙的よりも優れている」という格言を引用できます。他のプログラマーがこのスタイル (スタイル 2) を使用しているのを見てきました。

スタイル 2 に見られる主な利点は保守性です。特にダック タイピングの理想では、some_module を some_other_module に交換したいと思うかもしれません。また、スタイル 2 は「読みやすさが重要」という格言でポイントを獲得していると感じています。私は反対する傾向がありますが、検索と置換は、最初のスタイルを使用する場合と同様に優れたオプションであると常に主張できます。

補遺:スタイル 1 で からへasの切り替えを解決するために使用できることに注意してください。現在のモジュールに実装することを決定することも一般的であることを忘れていました。これにより、同等のコンテナーの作成が少し厄介になります。some_modulesome_other_modulesome_identifiersome_module

「ダックタイピング」の意味を誤解していないことを願っていますが、私が読んだことから、オブジェクトがどのタイプ/クラスであるかではなく、メソッドにどのように応答するかに基づいてコードを記述する必要があることを意味します。

コードは次のとおりです。

私が望むのは、キーが ActiveRecord オブジェクトの ID を表す整数であるハッシュになるようにすることです。all?IDを取得する必要があるかどうかを判断するために、ハッシュキーを2回反復処理する必要があるのは特に好きではありません。

もちろん、このコードを改善するための他の提案も受け入れます:)

Anders によると、C#4.0 では、動的型、または「静的型が動的」なオブジェクトを取得します。これにより、メソッド呼び出しの解決をコンパイル時ではなく実行時に行うことができます。しかし、有効である可能性が低いことがわかっている場合でも、動的オブジェクトの呼び出しを許可するのではなく、動的オブジェクトを何らかのコントラクトにバインドする (したがって、完全なインテリセンスを取得する) 機能はありますか?

つまり、ただの代わりに

次のような既知のコントラクトに制約するためにキャストまたは変換する機能があります。

または単に

C#4.0 の既存の資料にはそのようなものは見つかりませんが、動的パラダイムの論理的な拡張のようです。もっと情報を持っている人はいますか？

メンバーを宣言するときにインターフェイスを指定できますか?

この質問についてしばらく考えた後、静的ダック型の言語が実際に機能する可能性があることに気づきました。定義済みクラスをコンパイル時にインターフェイスにバインドできないのはなぜですか? 例：

そのような機能をサポートする言語を知っていますか? Java または C# で役に立ちますか? 何らかの形で根本的に欠陥がありますか？MyClass をサブクラス化してインターフェイスを実装したり、Adapter デザイン パターンを使用して同じことを達成したりできることは理解していますが、これらのアプローチは不必要なボイラープレート コードのように思えます。

「ダックタイピング」というフレーズが頻繁に使われ、1 つまたは 2 つのコード例に出くわすことさえあります。私は忙しすぎて自分の研究をすることができません。誰か簡単に教えていただけますか?

• 「ダックタイプ」とオールドスクールの「バリアントタイプ」の違い、および
• バリアント型入力よりもダック型入力を好む可能性がある例を示します。
• ダックタイピングを使用して達成する必要があるものの例を教えてください。

私は、この「新しい」構造の力を疑うことで、野鳥のように見えるつもりはありません。また、研究を拒否することで問題を回避しているわけでもありません。最近それ。私にはタイピング (別名動的タイピング) がないように見えるので、すぐには利点がわかりません。

補遺: これまでの例をありがとう。'O->can(Blah)' のようなものを使用することは、リフレクション ルックアップを実行することと同等であり (おそらく安くはありません)、および/または (O は IBlah) コンパイラーがあなたをチェックすることはできますが、後者には私の IBlah インターフェイスとあなたの IBlah インターフェイスを区別できるという利点がありますが、他の 2 つにはありません。確かに、メソッドごとにたくさんの小さなインターフェースが浮かんでいると面倒になりますが、多くの個々のメソッドをチェックすることもできます...

...だからまた私はそれを得ていません。それは素晴らしい時間の節約になりますか、それとも新品の袋に入った同じ古いものですか? ダックタイピングが必要な例はどこにありますか?

私は最近、Java や C# のような言語で、メソッドのパラメーターの型として「ダック」型を含めることは、構文糖衣の良い形になるだろうかと考えていました。これは次のようになります。

これは、リフレクションを介して doStuff() を呼び出すためのシンタックス シュガーになるか、別の方法で実装される可能性があります。Foo はどのタイプでもかまいません。foo に doStuff() メソッドがない場合、実行時例外がスローされます。要点は、必要なときに、つまりほとんどの場合、事前に指定されたより厳密なインターフェイス パラダイム (パフォーマンス、エラー チェック) の利点が得られるということです。同時に、ダッキング タイピングへのシンプルできれいに見えるバックドアができ、大規模なリファクタリングを行わなくても、初期設計では予期されていなかった変更をきれいに行うことができます。さらに、100% 後方互換性があり、既存の言語構造と完全に調和する可能性があります。これは、API を混乱させ、乱雑にする原因となる過度に設計された場合に備えたプログラミング スタイルを削減するのに役立つと思います。

現在、私の主要な言語は D です。また、受講しているコースで Python が必要になるため、Python を学習中です。型推論やテンプレートを使わずに静的言語でプログラミングする人々にとって、動的言語が新鮮な空気の息吹になる理由は理解できますが (私見のテンプレートは、コンパイル時のダックタイピングが大部分を占めています)、動的言語の利点が何であるかに興味があります。あなたがそれらを持っていても。

要するに、私が Python を学ぶつもりなら、単に Python で D を書くのではなく、プログラミングに対する私の考え方を本当に変えるような方法で学びたいということです。私はかなり初心者のプログラマーだったので動的言語を使用しておらず、動的言語が提供すると思われる柔軟性を理解できず、今それらを最大限に活用する方法を学びたいと思っています。テンプレート、ポリモーフィズム、静的型推論、そしておそらく実行時リフレクションを使用しても、静的言語では扱いにくい、または不可能な、動的に型付けされたインタープリター言語で簡単/エレガントに実行できることは何ですか?

Rubyを説明するテキストを読んでいて、次のように書かれていました。

Rubyは、Rubyプログラムがそれ自体を分析し（構成の観点から）、動作方法を調整し、さらには独自のコードを他のコードで上書きする可能性があるため、「反射」言語と見なされます。

私はこの用語「反射的」と混同しています-これは主に、Rubyが変数を調べて、それが整数か文字列か（ダックタイピング）を判断する方法について話しているものです。例：