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

29

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.

language-design

— usuario1446
fuente

44

Simplemente como alguien que programa en scala: los objetos complementarios separan el código para métodos estáticos y no estáticos, pueden extender otras clases o interfaces en un contexto estático, y puede hacer referencia al objeto complementario en una variable. sin embargo

— Phoenix

¿Los métodos estáticos y demás tienen alguna ventaja significativa sobre los objetos complementarios?

— Tanner Swett

Esta no es la razón, más una observación, pero he visto que tan pronto como los programadores principiantes (absolutos) descubren la staticpalabra clave en Java, se propaga inmediatamente a todos los rincones del programa porque aún no se les ha enseñado programación orientada a objetos. .

— Score_Under

30

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.

— JimmyJames
fuente

2

Ese es un buen punto. Y siempre he pensado que era extraño que haya singletons y estadísticas que tengan comportamientos muy similares, pero con nada más que objetos complementarios, elimina esa rareza conceptual.

— user1446

1

Y esto es exactamente por qué en Java prefiero definir métodos en objetos sin estado construidos estáticamente en lugar de definir métodos estáticos.

— candied_orange

13

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.

— Doc Brown
fuente

6

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

— Jörg W Mittag
fuente

1

"Otro aspecto es la simplicidad: ¿por qué tener dos cosas, objetos con miembros de instancia y clases con miembros estáticos cuando solo se pueden tener objetos con miembros de instancia?": Buen punto, aunque no todos los lenguajes / diseñadores de idiomas apuntan al minimalismo. Algunos ven como una ventaja tener construcciones ad-hoc para casos especiales o modismos.

— Giorgio

1

Creo que es por lo menos discutible que Java no (un poco) implementar ese patrón. Por ejemplo, si tiene MyStaticClassalgunos staticmiembros, puede hacer referencia MyStaticClass.classpara obtener una Classinstancia para esa clase. Luego puede usar la reflexión para acceder / invocar a sus staticmiembros. Todavía es cierto que los staticmiembros no están realmente vinculados a ninguna instancia de objeto (al menos conceptualmente; no estoy seguro de lo que Java realmente hace bajo las cubiertas). Pero sí significa que al menos algunos de los límites planteados en la respuesta aceptada no se aplican estrictamente .

— Aroth