2015-01-23 11 views
5

Questo script Groovy funziona benissimo:Perché non scrivere in maiuscolo il nome della classe causa qui un errore del compilatore?

println 0; 
class MyClass 
{ 
    public MyClass(int j) {}; 
    public MyClass method() {return this}; 
} 

Questo fallisce con un errore di compilazione ("token imprevisto: pubblico alla riga: 5, colonna: 4")

println 0; 
class myClass 
{ 
    public myClass(int j) {}; 
    public myClass method() {return this}; 
} 

L'unica differenza è il maiuscola del nome della classe. So che la convenzione prevede che i nomi delle classi siano in maiuscolo, ma ho pensato che fosse solo una convenzione. Cosa causa esattamente l'errore di compilazione?

risposta

7

Secondo un Groovy mailing list thread dal 2008, dove è stata posta una domanda simile, Paul King ha spiegato:

Sì, la grammatica attualmente appare per i tipi di maiuscole solo in dichiarazioni (a parte i tipi primitivi).

In un più recente, unresolved Groovy JIRA ticket per quanto riguarda i nomi delle classi minuscole, i commenti blackdrag che:

Il problema è che in Groovy (a differenza di Java) i nomi delle variabili, i nomi dei metodi e dei nomi delle classi possono condividere un contesto, rendendolo ambiguo.

Escludendo un'esplorazione più approfondita del tokenizer, aggiungerò questa come un'altra incoerenza minore tra Java e Groovy a causa della flessibilità della sintassi di Groovy. E invece di implementare completamente un modo per dire se un token è un tipo o un nome di metodo in questo contesto, Groovy prende una scorciatoia e assume solo che possa essere un nome di tipo se il token corrisponde a una primitiva o inizia con una lettera maiuscola, come sarebbero i tipi di Java convenzionali.

+0

Si dice "_un'altra incoerenza minore tra Java e Groovy a causa della flessibilità della sintassi di Groovy_", ma direi che Groovy sta semplicemente ** spostando l'inflessibilità ** da un luogo a un altro. Groovy sta diventando più _inflessibile_ nel non consentire nomi di classi minuscole, il prezzo pagato per diventare più _flessivo_ nel consentire ai nomi di classe di condividere un contesto con nomi di variabili e metodi. –

+0

Buon punto. Suppongo che questo sia uno dei vantaggi del non avere uno specifico linguaggio formale - puoi spostare l'inflessibilità in aree dove è più tollerabile che esista dal punto di vista della praticità. Quando Groovy è partito, hanno usato la sua compatibilità con la sintassi Java come punto di forza. Al giorno d'oggi, hanno sembrato de-enfatizzare quell'aspetto e vendere Groovy sulle sue altre caratteristiche (controllo di tipo statico opzionale, creazione di DSL, programmazione funzionale, ...), specialmente da quando Java 8 è caduto. – bdkosher

+0

voglio solo aggiungere che questa "inflessibilità" esiste già da molto tempo, raggiungendo il tempo di Strachan. Il commento sul ticket JIRA che ho realizzato in quel momento era più legato alla possibilità che l'utente scrivesse "foo = bar" e il compilatore non fosse in grado di vedere chiaramente se la barra dovrebbe essere una variabile (possibilmente dinamica) o una classe. Normalmente puoi facilmente aggirare problemi come questo con "importa come". Ma la domanda originale sopra sembra un bug per me in realtà. – blackdrag

Problemi correlati