Uso di "this" in Golang

Dovremmo chiedere all'autore di quella guida di stile di saperlo con certezza, ma penso che il motivo principale per cui sono d'accordo con lui sia che la connessione tra struct e method è molto più loose in Go di altri lingue .

In sostanza, quando scrivi un metodo come questo:

func (m *MultiShape) area() float64 {
  ...
}

È quasi esattamente la stessa cosa che scrivere una funzione come questa:

func area(m *MultiShape) float64 {
  ...
}

L'unica differenza è una leggera modifica della sintassi nel modo in cui chiamiamo la funzione / metodo.

In altre lingue la this / self / qualunque variabile ha tipicamente alcune proprietà speciali come essere magicamente fornite dalla lingua, o avere accesso speciale a metodi privati (ricorda che Go non ha campi / metodi privati) . Anche se il "ricevitore" viene ancora "magicamente fornito" in una certa misura, è così simile a un argomento di funzione normale che probabilmente non conta.

Inoltre, nei linguaggi OOP "tradizionali" i metodi struct / class vengono tutti con la definizione struct / class, in modo tale che non è possibile aggiungere altro dall'esterno. In Go, per quanto ne so chiunque può aggiungere più metodi a qualsiasi cosa (nell'ambito del proprio codice, ovviamente).

Non ho scritto abbastanza Vai a creare la mia guida di stile, ma personalmente userò probabilmente this in metodi definiti nello stesso file della struct che ricevono, e qualche altro nome descrittivo del destinatario su metodi che allegare alle strutture da altri file.

Non sono convinto da questa guida allo stile e non penso che nulla sia migliore di this , me o self . Poiché this , me o self rendono superfluo che la variabile sia un'istanza della struttura di contesto. Non sto dicendo che una variabile del nome della struttura con una cassa inferiore sia una cattiva idea, mi piace solo il modo in cui this lo rende super trasparente.

Questo è da una prospettiva di JavaScript dove this ha una vera parola chiave che significa il compilatore, ma dalla mia comprensione, se stanno bene con le abbreviazioni a due lettere per il tipo di oggetto, dovrebbe essere abbastanza facile da usare anziché. La ragione della differenza è che in un blocco decentemente ampio di codice asincrono progressivamente più profondo, potrebbe essere molto facile interpretare erroneamente cosa "questo", o il destinatario, si trova in un contesto più profondo; ed è possibile che non sia lo stesso oggetto.

Ad esempio in JavaScript, un modulo di controllo potrebbe avviare una finestra di dialogo e dichiarare una funzione onLoad in linea per esso. Ma a quel punto, potrebbe essere molto facile per un altro codificatore interpretare erroneamente this all'interno di onLoad per fare riferimento al modulo di controllo, non alla finestra di dialogo; o vice versa. Questo potrebbe essere evitato se il controllo fosse chiamato ctrl e il dialogo come dg .