Perché non esiste una parola chiave statica in Kotlin?

29

Kotlin è noto principalmente come sostituto drop-in per Java, ma elimina un noto costrutto Java: la staticparola chiave. Al contrario, tale funzionalità a livello di classe è offerta principalmente dagli oggetti companion.

Cosa c'è di sbagliato nei metodi e nei campi statici a cui gli oggetti associati forniscono un'alternativa migliore? Sono confuso riguardo alla logica e non ho trovato alcuna spiegazione nella documentazione.

language-design

— user1446
fonte

4

Basta guardare come qualcuno che programma in scala: gli oggetti companion separano il codice per metodi statici e non statici, possono estendere altre classi o interfacce in un contesto statico e puoi fare riferimento all'oggetto compagno in una variabile. non sono sicuro di come si associ a Kotlin

— Phoenix,

I metodi statici e quali altri vantaggi significativi rispetto agli oggetti companion?

— Tanner Swett,

Questo non è il motivo, più un'osservazione, ma ho visto che non appena i programmatori (assoluti) per principianti scoprono la staticparola chiave in Java, si propaga immediatamente in tutti gli angoli del programma perché non hanno ancora imparato la programmazione orientata agli oggetti .

— Score_Under

30

Scala sostituisce anche le dichiarazioni a livello di classe con un oggetto 'Singleton'. Il vantaggio principale di questo è che tutto è un oggetto. In Java, i membri statici vengono trattati in modo molto diverso rispetto ai membri dell'oggetto. Ciò significa che non puoi fare cose come implementare un'interfaccia o mettere la tua "istanza" di classe in una mappa o passarla come parametro a un metodo che accetta Object. Gli oggetti associati consentono queste cose. Questo è il vantaggio.

— JimmyJames
fonte

2

È un buon punto. E ho sempre pensato che fosse strano che ci fossero singoli e statici che avevano comportamenti molto simili, ma con nient'altro che oggetti compagni, elimina questa stranezza concettuale.

— user1446,

1

Ed è esattamente per questo che in Java preferisco definire metodi su oggetti stateless costruiti staticamente piuttosto che definire metodi statici.

— candied_orange,

13

Citando dai documenti di riferimento di Kotlin :

Si noti che, anche se i membri degli oggetti companion sembrano membri statici in altre lingue, in fase di esecuzione sono comunque membri di istanza di oggetti reali e, ad esempio, possono implementare interfacce.

Mi sembra molto che i designer di Kotlin vedano questo come un vantaggio rispetto ai membri statici di Java.

Inoltre, la parte relativa all'interoperabilità di Java e ai membri statici spiega come gli oggetti associati possono essere utilizzati per creare membri che si comportano in modo efficace come membri statici quando annotati @JvmStatic.

— Doc Brown
fonte

6

Kotlin è un linguaggio orientato agli oggetti. In un linguaggio orientato agli oggetti, qualcosa che non è un oggetto è una limitazione estremamente paralizzante. Le classi non sono oggetti, ma gli oggetti sono oggetti (duh!), Quindi la domanda dovrebbe piuttosto essere: perché una lingua non dovrebbe usare gli oggetti associati?

Un altro aspetto è la semplicità: perché avere due cose, oggetti con membri di istanza e classi con membri statici quando si possono avere solo oggetti con membri di istanza?

Un'alternativa che viene utilizzata in molti linguaggi derivati da Smalltalk è quella di rendere le classi stesse oggetti. Ad esempio, nelle classi Smalltalk sono istanze di una gerarchia parallela di metaclassi . In Ruby, le classi sono istanze della Classclasse (e sì, ciò significa che Classè un'istanza di se stessa). In tal caso, i "metodi di classe" sono in realtà solo normali metodi di istanza della metaclasse della classe. Non so perché questo disegno non sia stato scelto in Java (data la sua stretta relazione con Smalltalk), ma potrebbe avere qualcosa a che fare con la semplificazione del sistema di tipi (si noti che la maggior parte dei linguaggi con classi come oggetti tendono ad essere linguaggi dinamici).

— Jörg W Mittag
fonte

1

"Un altro aspetto è la semplicità: perché avere due cose, oggetti con membri di istanza e classi con membri statici quando si possono avere solo oggetti con membri di istanza?": Un buon punto, anche se non tutti i progettisti di linguaggi / linguaggi puntano al minimalismo. Alcuni vedono come un vantaggio avere costrutti ad hoc per casi speciali o modi di dire.

— Giorgio,

1

Penso che sia almeno discutibile che Java non (un po ') implementare quel modello. Ad esempio, se lo hai MyStaticClasscon alcuni staticmembri, puoi fare riferimento MyStaticClass.classper ottenere Classun'istanza per quella classe. È quindi possibile utilizzare la riflessione per accedere / invocare i propri staticmembri. È ancora vero che i staticmembri non sono effettivamente collegati a nessuna istanza di oggetto (almeno concettualmente; non sono sicuro di ciò che Java fa effettivamente sotto le copertine). Ciò significa che almeno alcuni dei limiti sollevati nella risposta accettata non si applicano rigorosamente .

— aroth