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

29

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.

language-design

— user1446
fonte

4

Apenas parecendo alguém que programa em objetos scala: companion separa o código para métodos estáticos e não estáticos, eles podem estender outras classes ou interfaces em um contexto estático e você pode fazer referência ao objeto complementar em uma variável. não sei como que mapeia para KOTLIN embora

— Phoenix

Os métodos estáticos e outros enfeites têm alguma vantagem significativa sobre os objetos complementares?

— Tanner Swett 28/08

Esse não é o motivo, é mais uma observação, mas vi que, assim que programadores iniciantes (absolutos) descobrem a staticpalavra - chave em Java, ela se propaga imediatamente para todos os cantos do programa, porque ainda não foi ensinada programação orientada a objetos .

— Score_Under

30

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.

— JimmyJames
fonte

2

Este é um bom ponto. E sempre achei estranho o fato de existirem singletons e estáticas que têm comportamentos muito semelhantes, mas com nada além de objetos complementares, isso acaba com essa estranheza conceitual.

— user1446

1

E é exatamente por isso que em Java eu prefiro definir métodos em objetos sem estado construídos estaticamente, em vez de definir métodos estáticos.

— Candied_orange 29/08/19

13

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.

— Doc Brown
fonte

6

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).

— Jörg W Mittag
fonte

1

"Outro aspecto é a simplicidade: por que ter 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?": Bom ponto, mesmo que nem todos os idiomas / designers de linguagem tenham como objetivo o minimalismo. Alguns vêem como uma vantagem ter construções ad-hoc para casos ou expressões especiais.

— Giorgio

1

Eu acho que é pelo menos discutível que Java não (um pouco) implementar esse padrão. Por exemplo, se você tiver MyStaticClassalguns staticmembros, pode fazer referência MyStaticClass.classpara obter uma Classinstância para essa classe. Você pode usar a reflexão para acessar / chamar seus staticmembros. Ainda é verdade que os staticmembros não estão realmente conectados a nenhuma instância do objeto (pelo menos conceitualmente; não tenho certeza do que o Java realmente faz nos bastidores). Mas isso significa que pelo menos alguns dos limites levantados na resposta aceita não se aplicam estritamente .

— Aroth 29/08/19