A JetBrains está testando no Kotlin 2.5.0 dois novos mecanismos chamados Companion Blocks e Companion Extensions, com o objetivo de ampliar a forma de definir membros associados ao tipo e melhorar a interoperabilidade entre diferentes plataformas Kotlin. A empresa afirma que o novo design abre possibilidades para padrões de programação que não estavam facilmente disponíveis usando os Companion Objects tradicionais.
O que o novo mecanismo acrescenta?
Os membros associados ao tipo são usados para definir constantes, ferramentas e funções de construção que não pertencem a um objeto individual, como uma constante que representa o vetor nulo ou uma função que cria um vetor de acordo com um ângulo específico. Antes, esse uso dependia dos Companion Objects, enquanto os novos blocos companion permitem escrever esse tipo de membro com uma sintaxe mais próxima de sua definição dentro do próprio tipo.
Já as Companion Extensions permitem adicionar membros associados a qualquer classe ou interface, mesmo quando o desenvolvedor não é proprietário do código original e mesmo quando o tipo vem do Java ou não contém originalmente um Companion Object. Isso significa que é possível estender tipos externos sem modificar sua definição básica.
Mudanças na compilação e na compatibilidade
O novo mecanismo difere dos Companion Objects em sua estratégia de compilação. Na plataforma JVM, os Companion Blocks são compilados como membros static, o que aproxima seu comportamento dos membros estáticos de outras plataformas. A JetBrains considera que isso pode beneficiar o Kotlin Multiplatform, pois é possível definir membros esperados em um bloco companion e então implementá-los usando uma classe Java que contenha membros static.
Mas os recursos ainda são experimentais. Para ativar os Companion Blocks, é necessário usar a opção -Xcompanion-blocks, enquanto a combinação de blocos e extensões requer a opção -Xcompanion-blocks-and-extensions.
Limitações do uso experimental
Ao usar Companion Extensions, o compilador produz arquivos binários de pré-lançamento. Portanto, outros projetos ou bibliotecas talvez não consigam consumir bibliotecas que utilizem essas extensões como dependências até que o recurso seja oficialmente estabilizado. A mesma limitação não se aplica à exposição de Companion Blocks, mas seus usuários também precisarão ativar o recurso.
É necessário migrar os Companion Objects?
A JetBrains não recomenda uma migração imediata. Os Companion Objects continuam sendo uma parte essencial do Kotlin, e seu suporte completo é garantido. Os Companion Blocks podem ser a opção preferida para código novo na maioria dos casos, mas os Companion Objects continuam sendo necessários em determinadas situações, como quando o companion precisa implementar uma interface, pois eles são compilados como uma classe completa.
Na prática, em muitos casos pode ser suficiente remover a palavra object para passar a usar um Companion Block, mas o projeto e todo o código que depende dele precisarão ser recompilados. A JetBrains também alerta que algumas ferramentas do ecossistema talvez ainda não estejam preparadas para lidar com a nova sintaxe.
Por que esse desenvolvimento é importante?
A mudança é importante para desenvolvedores do Kotlin Multiplatform e autores de bibliotecas, pois tenta reduzir a diferença entre o conceito de membros estáticos na JVM e em outras plataformas. No entanto, seu valor prático atualmente continua vinculado a uma fase experimental e à velocidade com que as ferramentas de compilação, as bibliotecas e os editores serão atualizados. Por isso, os Companion Blocks parecem adequados para experimentação e avaliação do design, mas não como base segura para uma migração ampla antes da estabilização do recurso.