提案されているデフォルトインターフェイスメソッド機能は、C# における多重継承、あるいはF#などの他の言語の多重継承の限定的な形を許可するものだ。Javaのデフォルトメソッドに影響を受け、ライブラリの作者たちは、デフォルトの実装を含めても後方互換を失うことなく、新しいメソッドを公開されたインターフェイスに追加できるようになるだろう。
これは討論の両サイドから強い意見が飛び交うホットな機能だ。その点については何も変わっていない。新しい情報は、 .NET Core のみの機能となる可能性があるということだ。
F＃におけるデフォルトインターフェイスメソッドの提案での議論では、Microsoft の Phillip Carter 氏は次のように述べた。
デフォルトインターフェイスメソッドは #243 をサポートするために .NET ランタイムでサポートされている方法を提供しています。しかし、この変更は .NET Core のみで利用可能となるでしょう。なぜならば、基底にあるランタイム機能をサポートするためにデスクトップ CLR の変更するのはまずありえないからです。そのため C# と同様に F# は Core CLR を利用するときのみに動作する機能をもつことになるでしょう。
[…]
デフォルトインターフェイスメソッドはランタイムの変更が必要です。すなわち、この機能がランタイム https://github.com/dotnet/csharplang/blob/master/proposals/default-interface-methods.md#clr-support-api でサポートされるかどうかを確かめる必要がある、ということを意味します。
これをサポートしている .NET Framework のバージョンはリリースされていません。また既に広まっているアプリケーションを破壊するリスクを犯すことはまずありえないでしょう。 .NET Core は最終的にこの機能を得るでしょうが、将来的に .NET Framework や mono、 UWP ランタイムでもサポートされるかどうかは完璧には解決されていません。また @jnm2 が言及しているように .NET Standard をサポートするすべてのランタイムがこの機能をもたなければ、 .NET Standard で利用することはできません。次期の .NET Standard 2.1 ではその計画はありません。
私の心にある問いは、長期的計画という観点において、そうした構造に直面して失敗しないことを保証するために何をすべきか、ということです。 C# の機能をコピーする？おそらく違うでしょう。一人前のトレイト/型クラスのシステムを用意することでしょうか？そのためにはそれを実現するための適切な設計が必要でしょう。 SRTP のような既存のものを合理化するためにどうすればよいでしょうか？今日のインターフェイス、明日のインターフェイス、インターフェイスとしての関数、通常のジェネリクス、SRTP、（他にも何かある？）それぞれの整合性についてどう考えたらよいでしょうか？しかし少なくとも私の心にあるのは、実装のための何らかのメカニズムが生まれるということ、そして、高いレベルに存在するものは何か、それがどういった振る舞いをするか、このスペースで挙げられた既存の機能を合理化するためにどうするか、を考えることは勝ちがあるだろう、ということです。
C# の提案スレッドでは Joseph Musser 氏が以下のように反応した。
ライブラリ作者として、もしライブラリのターゲットが .NET Framework や .NET Framework が動作する .NET Standard のあるバージョンであれば、 API に関連する今日のシチュエーションにおいて DIM は使用されなくなる、ということを意味します。インターフェイスメソッドを追加することは依然として破壊的変更なのです。
Thomas Levesque 氏はさらに “また、この機能においてライブラリこそが最も重要なユースケースであるため、機能全体がほぼ無意味になるでしょう...” と付け加えた。
Rate this Article
- Editor Review
- Chief Editor Action