Pourquoi n'y a-t-il pas de mot-clé statique dans Kotlin?

29

Kotlin est principalement connu pour remplacer Java, mais il se débarrasse d'une construction Java bien connue: le staticmot - clé. Au lieu de cela, cette fonctionnalité au niveau de la classe est principalement proposée par les objets compagnons.

Quel est le problème avec les méthodes statiques et les champs que les objets compagnons fournissent une meilleure alternative? Je suis confus quant à la justification et je n'ai trouvé aucune explication dans la documentation.

language-design

— user1446
source

4

En observant simplement quelqu'un qui programme dans scala: les objets compagnons séparent le code des méthodes statiques et non statiques, ils peuvent étendre d'autres classes ou interfaces dans un contexte statique, et vous pouvez référencer l'objet compagnon dans une variable. je ne sais pas comment cela correspond à kotlin

— Phoenix

Les méthodes statiques et ainsi de suite ont-elles un avantage significatif par rapport aux objets compagnons?

— Tanner Swett du

Ce n'est pas la raison, plus une observation, mais j'ai vu que dès que les programmeurs débutants (absolus) découvrent le staticmot - clé en Java, il se propage immédiatement à tous les coins du programme car ils n'ont pas encore appris la programmation orientée objet .

— Score_Under

30

Scala remplace également les déclarations de niveau classe par un objet 'Singleton'. Le principal avantage de cela est que tout est un objet. En Java, les membres statiques sont traités très différemment des membres d'objet. Cela signifie que vous ne pouvez pas faire des choses comme implémenter une interface ou mettre votre classe «instance» dans une carte ou la passer comme paramètre à une méthode qui prend Object. Les objets compagnons permettent ces choses. Voilà l'avantage.

— JimmyJames
source

2

C'est un bon point. Et j'ai toujours pensé que c'était bizarre qu'il y ait des singletons et des statiques qui ont des comportements très similaires, mais avec rien d'autre que des objets compagnons, cela supprime cette bizarrerie conceptuelle.

— user1446

1

Et c'est exactement pourquoi en Java, je préfère définir des méthodes sur des objets sans état construits statiquement plutôt que de définir des méthodes statiques.

— candied_orange

13

Citant les documents de référence de Kotlin :

Notez que, même si les membres des objets compagnons ressemblent à des membres statiques dans d'autres langages, ceux-ci sont toujours des membres d'instance d'objets réels et peuvent, par exemple, implémenter des interfaces.

Cela me semble beaucoup comme si les concepteurs de Kotlin y voyaient un avantage sur les membres statiques de Java.

De plus, la partie sur l'interopérabilité Java et les membres statiques explique comment les objets compagnons peuvent être utilisés pour créer des membres qui se comportent efficacement comme des membres statiques lorsqu'ils sont annotés @JvmStatic.

— Doc Brown
source

6

Kotlin est un langage orienté objet. Dans un langage orienté objet, quelque chose qui n'est pas un objet est une restriction extrêmement paralysante. Les classes ne sont pas des objets, mais les objets sont des objets (duh!), Alors la question devrait plutôt être: pourquoi un langage n'utiliserait-il pas des objets compagnons?

Un autre aspect est la simplicité: pourquoi avoir deux choses, des objets avec des membres d'instance et des classes avec des membres statiques alors que vous pouvez simplement avoir des objets avec des membres d'instance?

Une alternative utilisée dans de nombreux langages dérivés de Smalltalk est de faire des classes elles-mêmes des objets. Par exemple, dans les classes Smalltalk sont des instances d'une hiérarchie parallèle de métaclasses . Dans Ruby, les classes sont des instances de la Classclasse (et oui, cela signifie que Classc'est une instance d'elle-même). Dans ce cas, les "méthodes de classe" ne sont en fait que des méthodes d'instance normales de la métaclasse de la classe. Je ne sais pas pourquoi cette conception n'a pas été choisie en Java (étant donné sa proximité avec Smalltalk), mais cela peut avoir quelque chose à voir avec la simplification du système de types (notez que la plupart des langages avec des classes en tant qu'objets ont tendance à être langages dynamiques).

— Jörg W Mittag
source

1

"Un autre aspect est la simplicité: pourquoi avoir deux choses, des objets avec des membres d'instance et des classes avec des membres statiques alors que vous ne pouvez avoir que des objets avec des membres d'instance?": Bon point, même si tous les langages / concepteurs de langage ne visent pas le minimalisme. Certains y voient un avantage à avoir des constructions ad hoc pour des cas spéciaux ou des idiomes.

— Giorgio

1

Je pense qu'il est au moins possible de soutenir que Java ne ( un peu) mettre en œuvre ce modèle. Par exemple, si vous en avez MyStaticClassavec certains staticmembres, vous pouvez faire référence MyStaticClass.classpour obtenir une Classinstance pour cette classe. Vous pouvez ensuite utiliser la réflexion pour accéder / invoquer vos staticmembres. Il est toujours vrai que les staticmembres ne sont en fait attachés à aucune instance d'objet (du moins sur le plan conceptuel; je ne suis pas sûr de ce que Java fait réellement sous les couvertures). Mais cela signifie qu'au moins certaines des limites soulevées dans la réponse acceptée ne s'appliquent pas strictement .

— 2017