Metodi senza parametri e Paren vuoto in Scala

Attualmente sto imparando la Scala tramite la Scala di programmazione di Odersky (2a). Sono al capitolo 10 in cui inizia a introdurre metodi senza parametri e a paren vuoto. Non riesco proprio a pensarci bene.

Finora, tutto quello che capisco è che dovrei usare parens vuoti se un metodo ha effetti collaterali e metodi senza parametri altrimenti.

Non riesco a capire quale sia il vantaggio di questa convenzione. Ho letto i post su Stack Exchange, ma a dire il vero, quando i post iniziano a discutere di questo argomento in modo approfondito, mi sono perso.

Sto cercando una semplice spiegazione di quali sono i casi d'uso tipici di questa funzionalità linguistica e quali sono i vantaggi che mi aiutano a capirlo meglio.

Ho preso la tua domanda sul perché non progettare la lingua per evitare in primo luogo la necessità di una convenzione? In altre parole, perché Scala non impone sempre l'uso delle parentesi, invece di consentire ai programmatori di ometterle a volte?

La risposta si trova nella trasparenza referenziale . In sostanza, se una funzione non ha effetti collaterali, una chiamata di funzione può essere sostituita con il suo risultato, senza modificare il comportamento del programma.

Ciò significa che una funzione senza parametri o effetti collaterali è semanticamente equivalente a valmantenere il valore di ritorno di quella funzione. A causa di questa proprietà, man mano che una classe si evolve, il programmatore potrebbe passare avanti e indietro dall'uso di una valo dall'uso di una funzione, come richiesto dalla convenienza o dall'efficienza.

Dal momento che puoi omettere le parentesi, ciò significa che il codice che chiama qualcosa del genere queue.sizenon ha bisogno di sapere né preoccuparsi se sizeè una funzione o un val. L'implementatore della Queueclasse è quindi libero di cambiare tra i due senza dover modificare il codice chiamante (anche se credo che dovrà essere ricompilato). Stabilizza l'interfaccia pubblica della classe. Ad esempio, è possibile iniziare a queue.sizechiamando sizeun sottostante List, che è potenzialmente O(n), quindi passare sizea a valper motivi di efficienza.

La convenzione suggerisce le parentesi quando ci sono effetti collaterali per chiarire che questo membro della classe è sicuramente una chiamata di funzione e quindi potenzialmente non referenzialmente trasparente. È importante che il codice chiamante sappia se vengono prodotti effetti collaterali, in modo che possano evitare di chiamarlo ripetutamente. Se non ti importa se è una funzione o meno, puoi anche trattarla come se non lo fosse.

Questa è una convenzione, non fa parte del design del linguaggio. È usato come un cartello per aiutare le persone che devono leggere il codice dopo averlo scritto per capirlo meglio.

Dalla Guida allo stile di Scala sull'invocazione del metodo:

Scala consente l'omissione delle parentesi sui metodi di arity-0 (nessun argomento):

reply() 

// is the same as 

reply

Tuttavia, questa sintassi dovrebbe essere utilizzata solo quando il metodo in questione non ha effetti collaterali (puramente funzionali). In altre parole, sarebbe accettabile omettere le parentesi quando si chiama queue.size, ma non quando si chiama println().

L'osservanza religiosa di questa convenzione migliorerà notevolmente la leggibilità del codice e renderà molto più semplice comprendere a colpo d'occhio l'operazione più basilare di un determinato metodo. Resisti alla tentazione di omettere le parentesi semplicemente per salvare due personaggi!

In .NET, la convenzione prevede l'uso di metodi quando l'esecuzione del codice può richiedere del tempo (diciamo, più lunga di 50ms) e proprietà (essenzialmente metodi vuoti di paren) quando non lo farà (ovvero è una semplice ricerca).