Builder Inference annotation

Talvez você ainda não tenha escutado falar ou não sabe quando utilizar a anotação BuilderInference, eu mesmo via bastante nos códigos fontes da Google e sempre ignorava.

Hoje irei demonstrar o poder dessa anotação e o porque de ser constante utilizada em muitas bibliotecas.

Acredito que você em algum momento já escreveu alguma função genérica e gostaria que o tipo fosse automaticamente entendido pela IDE.

Olhe bem este exemplo

A IDE nos pede para especificar explicitamente o tipo da função listBuilder, ficando então assim:

Então não temos problemas, certo ?

Eu concordo em certo ponto !

Porém, olhe esse outro trecho de código

Isso acaba implicando na leitura do código, tornando mais confuso, seria muito mais limpo e mais rápido no nosso dia a dia se não precisamos de ter que em toda função de builder explicitar o tipo.

Vamos reparar alguns exemplos de funções já existentes na biblioteca do Android

Essa função tem como padrão de builder, repare como não precisamos escrever o tipo explicitamente, ficando mais simples e clara a implementação.

Como sabemos, o Kotlin vem sendo constantemente atualizado. Em uma atualização surgiu uma anotação bem interessante, essa anotação vem sendo utilizada em várias bibliotecas internas.

Vamos então ver o contrato dessa função e ver por que a IDE não reclama.

Damos aqui maior atenção ao argumento em destaque, repare que esse argumento tem a anotação que mencionei no logo no início do artigo.

A anotação BuilderInference, nos permite inferir tipos genéricos de uma função a partir das funções da interface genérica recebida no lambda.

Vamos então modificar nossa função listBuilder para que permita inferir argumentos também.

Repare que no contrato o argumento scope recebe uma interface do mesmo tipo da função.

e voilá!

Ressaltando a importância da interface recebida no lambda, temos que chamar métodos dela para a IDE entender o tipo genérico em questão !

Bônus !!

Lembre-se que a anotação está aberta para qualquer interface, nos permitindo várias possíbilidades, como por exemplo um construtor somente com função de adicionar:

Com nossa interface, podemos criar um contrato com escopo fechado para outras ações na lista.

Tendo mesmo resultado de adição que a interface mutável de listas do Kotlin !

Lembrando que essa anotação ainda está em experimental, então temos que adicionar a anotação