¿Por qué no hay una palabra clave estática en Kotlin?

Kotlin se conoce principalmente como un reemplazo directo para Java, pero se deshace de una construcción Java conocida: la staticpalabra clave. En cambio, esa funcionalidad de nivel de clase es ofrecida principalmente por objetos complementarios.

¿Qué hay de malo en los métodos y campos estáticos para los que los objetos complementarios ofrecen una mejor alternativa? Estoy confundido acerca de la razón y no pude encontrar ninguna explicación en la documentación.

Scala también reemplaza las declaraciones de nivel de clase con un objeto 'Singleton'. La principal ventaja de esto es que todo es un objeto. En Java, los miembros estáticos se tratan de manera muy diferente a los miembros de objetos. Esto significa que no puede hacer cosas como implementar una interfaz o poner su 'instancia' de clase en un mapa o pasarla como parámetro a un método que toma Object. Los objetos complementarios permiten estas cosas. Esa es la ventaja.

Citando de los documentos de referencia de Kotlin :

Tenga en cuenta que, aunque los miembros de los objetos complementarios se vean como miembros estáticos en otros idiomas, en el tiempo de ejecución siguen siendo miembros de objetos reales y, por ejemplo, pueden implementar interfaces.

Me parece mucho que los diseñadores de Kotlin vean esto como una ventaja sobre los miembros estáticos de Java.

Además, la parte sobre la interoperabilidad de Java y los miembros estáticos explica cómo se pueden usar los objetos complementarios para crear miembros que se comporten efectivamente como miembros estáticos cuando se anotan @JvmStatic.

Kotlin es un lenguaje orientado a objetos. En un lenguaje orientado a objetos, algo que no es un objeto es una restricción extremadamente paralizante. Las clases no son objetos, pero los objetos son objetos (¡duh!), Por lo que la pregunta debería ser: ¿por qué un lenguaje no usaría objetos complementarios?

Otro aspecto es la simplicidad: ¿por qué tener dos cosas, objetos con miembros de instancia y clases con miembros estáticos cuando solo puede tener objetos con miembros de instancia?

Una alternativa que se usa en muchos lenguajes derivados de Smalltalk es hacer que las clases sean objetos. Por ejemplo, en Smalltalk las clases son instancias de una jerarquía paralela de metaclases . En Ruby, las clases son instancias de la Classclase (y sí, eso significa que Classes una instancia de sí misma). En ese caso, los "métodos de clase" son en realidad métodos de instancia normales de la metaclase de la clase. No sé por qué este diseño no se eligió en Java (dada su estrecha relación con Smalltalk), pero puede tener algo que ver con la simplificación del sistema de tipos (tenga en cuenta que la mayoría de los lenguajes con clases como objetos tienden a ser lenguajes dinámicos).