Por que não existe palavra-chave estática no Kotlin?

O Kotlin é conhecido principalmente como um substituto para Java, mas elimina uma construção Java conhecida: a staticpalavra - chave. Em vez disso, essa funcionalidade em nível de classe é oferecida principalmente por objetos complementares.

O que há de errado com métodos e campos estáticos aos quais os objetos complementares fornecem uma alternativa melhor? Estou confuso com a justificativa e não consegui encontrar nenhuma explicação na documentação.

Scala também substitui declarações em nível de classe por um objeto 'Singleton'. A principal vantagem disso é que tudo é um objeto. Em Java, os membros estáticos são tratados de maneira muito diferente dos membros do objeto. Isso significa que você não pode fazer coisas como implementar uma interface ou colocar sua 'instância' da classe em um mapa ou passá-la como parâmetro para um método que utiliza Object. Os objetos complementares permitem essas coisas. Essa é a vantagem.

Citando os documentos de referência da Kotlin :

Observe que, embora os membros de objetos complementares pareçam membros estáticos em outros idiomas, em tempo de execução, eles ainda são membros de instância de objetos reais e podem, por exemplo, implementar interfaces.

Parece muito para mim como os designers do Kotlin veem isso como uma vantagem sobre os membros estáticos do Java.

Além disso, a parte sobre interoperabilidade Java e membros estáticos explica como os objetos complementares podem ser usados ​​para criar membros que se comportam efetivamente como membros estáticos quando anotados @JvmStatic.

Kotlin é uma linguagem orientada a objetos. Em uma linguagem orientada a objetos, algo que não é um objeto é uma restrição extremamente incapacitante. Classes não são objetos, mas objetos são objetos (duh!), Então a pergunta deveria ser: por que uma linguagem não usaria objetos complementares?

Outro aspecto é a simplicidade: por que duas coisas, objetos com membros da instância e classes com membros estáticos quando você pode apenas ter objetos com membros da instância?

Uma alternativa usada em muitas linguagens derivadas do Smalltalk é tornar as próprias classes objetos. Por exemplo, nas classes Smalltalk, são instâncias de uma hierarquia paralela de metaclasses . No Ruby, classes são instâncias da Classclasse (e sim, isso significa que Classé uma instância em si). Nesse caso, "métodos de classe" são na verdade apenas métodos de instância normais da metaclasse da classe. Não sei por que esse design não foi escolhido em Java (devido à sua relação com Smalltalk), mas pode ter algo a ver com a simplificação do sistema de tipos (observe que a maioria das linguagens com classes como objetos tendem a ser linguagens dinâmicas).