問題タブ [structural-typing]

ウィキペディアはダックタイピングについて次のように述べていました:

オブジェクト指向プログラミング言語を使用したコンピューター プログラミングでは、ダック タイピングは動的型付けのスタイルであり、特定のクラスからの継承や特定のインターフェイスの実装ではなく、オブジェクトの現在のメソッドとプロパティのセットによって有効なセマンティクスが決定されます。

_{(* 編集者注: この質問が投稿されて以来、ウィキペディアの記事は編集され、「動的」という単語が削除されました。)}

構造型付けについて次のように述べています。

構造型システム (またはプロパティ ベースの型システム) は、型システムの主要なクラスであり、型の互換性と等価性は、明示的な宣言ではなく、型の構造によって決定されます。

次のように、構造的サブタイピングとダックタイピングを対比します。

[構造システム] は、実行時にアクセスされる構造の一部のみが互換性をチェックされる ... ダック タイピングとは対照的です。

しかし、ダックタイピングという用語は、少なくとも構造的なサブタイピングシステムを直感的に包含しているように思えます。実際、ウィキペディアには次のように書かれています。

概念の名前 [ダックタイピング] は、ジェームズ ウィットコム ライリーによるアヒル テストを指し、次のように表現できます。「アヒルのように歩き、アヒルのように泳ぎ、アヒルのように鳴く鳥を見たとき私はその鳥をアヒルと呼んでいます。」

だから私の質問は: 構造的サブタイピングをダックタイピングと呼べないのはなぜですか? ダック型として分類できない動的型付け言語も存在しますか?

追記:

reddit.com でdaydreamdrunkという名前の誰かが雄弁に言ったように、「アヒルのようにコンパイルし、アヒルのようにリンクするなら...」

あとがき

多くの答えは、基本的に、ここで既に引用したことを再ハッシュしているだけのようで、より深い質問に対処していません。動的型付けと構造的サブタイピングの両方をカバーするためにダックタイピングという用語を使用しないのはなぜですか? 構造的なサブタイピングではなく、ダックタイピングについてのみ話したい場合は、動的メンバー検索と呼んでください。私の問題は、ダックタイピングという用語について何も言わないことです。これは動的言語にのみ適用されます。

なぜこれはwtfを出力するのですか? パターン マッチングは構造型では機能しませんか?

次の例を見てみましょう。

コンパイラは次のように述べています。

メソッド 'System.Linq.Enumerable.Select(System.Collections.Generic.IEnumerable, System.Func)' の型引数は、使用法から推測できません。型引数を明示的に指定してみてください。

に変換できないBarからFunc<IList<X>, int, IDictionary<Y, IList<Z>>>です。

C# でジェネリック型の型名前空間スコープの型エイリアスを作成できれば素晴らしいと思います。次にBar、デリゲートとして定義するのではなく、 の名前空間スコープのエイリアスとして定義しますFunc<IList<X>, int, IDictionary<Y, IList<Z>>>。

次に、たとえばの名前空間スコープのエイリアスを定義することもできますIDictionary<Y, IList<Z>>。

適切に使用すれば:)、コードが読みやすくなります。ここで、ジェネリック型をインライン化する必要があり、実際のコードはよく読めません:(

同じ問題を見つけましたか :)? C# 3.0 にない正当な理由はありますか? それとも、正当な理由はなく、単にお金や時間の問題ですか?

編集: を使用できることはわかってusingいますが、名前空間スコープではありません。私の場合はあまり便利ではありません。

EDIT2 : Jorenのコメントを参照してください。構造型付けでも問題が解決する可能性があることが示唆されています。

「追加」メソッドを持つコレクション (Java コレクションなど) を定義する構造型を定義しようとしています。これを使用して、特定のコレクションを操作するいくつかの高階関数を定義したいと思います

これは次のエラーでコンパイルされません

GenericCollection のパラメーターを削除して、メソッドに配置しようとしました:

しかし、別のエラーが発生します:

Scala で抽象型パラメーターを使用して構造型付けを使用する方法について、誰かアドバイスをもらえますか? または、私が達成しようとしていることを達成する方法は? 本当にありがとう！

Scala では、次のように構造型を定義できます。

type Pressable = { def press(): Unit }

これは、次のように、Pressable である何かを引数として取る関数またはメソッドを定義できることを意味します。

def foo(i: Pressable) { // etc.

この関数に渡すオブジェクトは、その型で定義された型シグネチャに一致する press() というメソッドを定義している必要があります。引数をとらず、Unit (Scala バージョンの void) を返します。

構造型をインラインで使用することもできます。

def foo(i: { def press(): Unit }) { // etc.

基本的に、プログラマーはダックタイピングのすべての利点を享受しながら、コンパイル時の型チェックの利点を得ることができます。

C# には似たようなものがありますか? 私はグーグルで検索しましたが、何も見つかりませんでしたが、C# について詳しく知りません。ない場合、これを追加する予定はありますか?

C++ でコンパイラに Ogre::Vector3 IS_SAME_AS SomeOtherLIB::Vector3 を伝える方法は? 私はそれを感じます..構造型ではないc ++のような言語では、それが理にかなっている場合があります。

通常、ソートまたは独自の Vector3 実装を提供する 4 つ以上のライブラリを使用するゲーム開発者として。コードには、ToOgre、ToThis、ToThat 変換関数が散らばっています。それは、最初に発生するべきではない多くの Float3 コピーです。

C ++または他の言語では、ある型から別の型に変換（コピー）する必要はありませんが、これは本質的に同じです。ただし、ほとんどの優れたゲーム開発ライブラリは c/c++ 用であるため、C++ でのソリューションはどれでも構いません。

次のように、 aと ainterpolateの 2 つのメソッドを持つ任意の型で機能するジェネリック メソッドを作成しようとしています。*+

これは機能しませんが (Scala 2.8.0.RC7 では)、次のエラー メッセージが表示されます。

構造型を正しく指定するにはどうすればよいですか? （または、これを行うより良い方法はありますか？）

特定の型をより一般的な構造型に適合させる問題に興味があります。次の例を検討してください。

非準拠のケースのそれぞれで、 のメソッドへの呼び出しはGeneral、 の対応するメソッドに安全に解決できますSpecific。この質問には、より興味深い実際の例があります。

ここで、Customer のcopyメソッドは、Versionable の自己型アノテーションの署名に準拠していません。ただし、コンパイラで許可されている場合は、 とcopy同じように呼び出すことができることに注意してくださいVersionable.incrementVersion。明らかに、Customer のメソッドの実際の署名は、オプションでパラメーターを指定copyできるという無関係な知識を持っているため、Versionable で使用するにはあまりにも具体的です。name

これらの制限を回避する方法はありますか? そのような一般化された適合が悪い考えになる理由はありますか?

Dubochet and Odersky's Compiling Structural Types on the JVMを読んでいて (わかりました、スキミング)、次の主張に混乱しました。

ジェネレーティブ手法は、JVM 上の構造型に代わる Java インターフェースを作成します。このような手法の複雑さは、プログラム内の任意の場所で構造型として使用されるすべてのクラスが適切なインターフェイスを実装する必要があることにあります。これがコンパイル時に行われると、個別のコンパイルが妨げられます。

（強調追加）

論文の autoclose の例を考えてみましょう:

次のような型のインターフェイスを生成できませんでしたCloseable:

の定義autocloseを

次に、 の呼び出しサイトを検討しますautoclose。

fisはFileInputStreamを実装していないため、AnonymousInterface1ラッパーを生成する必要があります。

何かが欠けているに違いありませんが、それが何であるかは不明です。このアプローチが個別のコンパイルを妨げるのはなぜですか?

with traits を使用し、構造型を型パラメーターの制約として使用するコードの一部に、再帰的な構造型が必要でした。問題なく動作しましたが、後で Scala が再帰構造型をサポートしていないことを知りました。

それで、誰かがこれがうまくいく理由を説明できますか：

これはそうではありません：