Dlaczego w Kotlin nie ma statycznego słowa kluczowego?

Kotlin jest znany przede wszystkim jako drop-in zamiennik Javy, ale pozbywa się dobrze znanego konstruktu Java: staticsłowa kluczowego. Zamiast tego ta funkcjonalność na poziomie klasy jest oferowana głównie przez obiekty towarzyszące.

Co jest złego w metodach statycznych i polach, dla których obiekty towarzyszące stanowią lepszą alternatywę dla? Jestem zdezorientowany uzasadnieniem i nie mogłem znaleźć żadnego wyjaśnienia w dokumentacji.

Scala zastępuje również deklaracje na poziomie klasy obiektem „Singleton”. Główną zaletą tego jest to, że wszystko jest przedmiotem. W Javie elementy statyczne są traktowane bardzo inaczej niż elementy obiektowe. Oznacza to, że nie możesz robić rzeczy takich jak implementacja interfejsu lub umieszczanie „instancji” klasy na mapie lub przekazywanie jej jako parametru do metody, która pobiera Object. Obiekty towarzyszące pozwalają na te rzeczy. To zaleta.

Powołując się na dokumenty referencyjne Kotlin :

Należy zauważyć, że chociaż elementy obiektów towarzyszących wyglądają jak elementy statyczne w innych językach, w czasie wykonywania są one nadal elementami rzeczywistymi obiektów i mogą na przykład implementować interfejsy.

Wydaje mi się, że projektanci Kotlin postrzegają to jako przewagę nad statycznymi elementami Javy.

Ponadto w części dotyczącej interoperacyjności Java i elementów statycznych wyjaśniono, w jaki sposób można używać obiektów towarzyszących do tworzenia elementów, które zachowują się skutecznie jak elementy statyczne, gdy są opatrzone adnotacjami @JvmStatic.

Kotlin jest językiem obiektowym. W języku obiektowym coś, co nie jest przedmiotem, jest wyjątkowo okaleczającym ograniczeniem. Klasy nie są obiektami, ale obiekty są obiektami (duh!), Więc pytanie powinno raczej brzmieć: dlaczego język nie miałby używać obiektów towarzyszących?

Innym aspektem jest prostota: dlaczego mają dwie rzeczy: obiekty z elementami instancji i klasy z elementami statycznymi, skoro można mieć tylko obiekty z elementami instancji?

Alternatywą stosowaną w wielu językach pochodzących z Smalltalk jest tworzenie obiektów jako klas. Np. W klasach Smalltalk występują instancje równoległej hierarchii metaklas . W Rubim klasy są instancjami Classklasy (i tak, to znaczy, że Classjest instancją samej w sobie). W takim przypadku „metody klasowe” są właściwie zwykłymi metodami instancji metaklasy klasy. Nie wiem, dlaczego ten projekt nie został wybrany w Javie (biorąc pod uwagę jego bliską relację z Smalltalk), ale może mieć coś wspólnego z uproszczeniem systemu typów (zwróć uwagę, że większość języków z klasami jako obiektami jest zwykle języki dynamiczne).