JetBrainsはKotlin 2.5.0で、Companion BlocksとCompanion Extensionsという2つの新しい仕組みを試験しています。目的は、型に関連付けられたメンバーの定義方法を拡張し、Kotlinの各プラットフォーム間の相互運用性を改善することです。同社によれば、新しい設計によって、従来のCompanion Objectsでは容易に利用できなかったプログラミングパターンが可能になります。
新しい仕組みは何を追加するのか？
型に関連付けられたメンバーは、ゼロベクトルを表す定数や、指定した角度に基づいてベクトルを生成する関数など、単独のオブジェクトに属さない定数、ユーティリティ、生成関数を定義するために使用されます。これまではこの用途にCompanion Objectsを使用していましたが、新しいコンパニオンブロックでは、この種のメンバーを型自体の内部で定義する場合に近い構文で記述できます。
一方、Companion Extensionsを使うと、開発者が元のコードの所有者でない場合でも、また型がJava由来である場合や、もともとCompanion Objectを持たない場合でも、任意のクラスまたはインターフェースに関連付けられたメンバーを追加できます。つまり、基本的な定義を変更せずに外部の型を拡張できます。
コンパイルと互換性の変更
新しい仕組みは、コンパイル戦略においてCompanion Objectsと異なります。JVMプラットフォームでは、Companion Blocksはstaticメンバーにコンパイルされるため、他のプラットフォームにおける静的メンバーに近い動作になります。JetBrainsは、これがKotlin Multiplatformに役立つ可能性があると見ています。コンパニオンブロックでexpectメンバーを定義し、staticメンバーを含むJavaクラスを使って実装できるためです。
ただし、これらの機能はまだ実験段階です。Companion Blocksを有効にするには-Xcompanion-blocksオプションが必要で、ブロックと拡張機能を組み合わせるには-Xcompanion-blocks-and-extensionsオプションが必要です。
実験的な利用における制限
Companion Extensionsを使用すると、コンパイラーはリリース前のバイナリファイルを生成します。そのため、この機能が正式に安定するまで、他のプロジェクトやライブラリは、これらの拡張機能を使用するライブラリを依存関係として利用できない可能性があります。同じ制限はCompanion Blocksの公開には適用されませんが、その利用者もこの機能を有効にする必要があります。
Companion Objectsを移行すべきか？
JetBrainsは即時の移行を推奨していません。Companion Objectsは依然としてKotlinの中核的な一部であり、完全なサポートが保証されています。多くの場合、新しいコードではCompanion Blocksが望ましい選択肢になる可能性がありますが、コンパニオンにインターフェースを実装させる必要がある場合など、Companion Objectsが引き続き必要なケースもあります。Companion Objectsは完全なクラスにコンパイルされるためです。
実際には、多くの場合、objectという語を削除するだけでCompanion Blockへ移行できますが、プロジェクトと、それに依存するすべてのコードを再コンパイルする必要があります。またJetBrainsは、エコシステムの一部のツールが新しい構文に対応する準備をまだ整えていない可能性があると警告しています。
なぜこの進展が重要なのか？
この変更は、Kotlin Multiplatformの開発者やライブラリの作者にとって重要です。JVMと他のプラットフォームにおける静的メンバーの概念の隔たりを縮めようとしているためです。ただし、現時点での実用的な価値は、実験段階にあることと、ビルドツール、ライブラリ、エディターがどれだけ速く更新されるかに左右されます。そのため、Companion Blocksは設計を試し評価する用途には適していますが、機能が安定する前に大規模な移行の安全な基盤として利用するものではないようです。