L'uso di "questo" in Golang

Sulla cosa più vicina Golang ha una guida di stile trovata qui , sotto Nomi dei ricevitori questo è scritto:

Il nome del destinatario di un metodo dovrebbe riflettere la sua identità; spesso è sufficiente un'abbreviazione di una o due lettere del suo tipo (come "c" o "cl" per "Cliente"). Non usare nomi generici come "io", "questo" o "sé", identificatori tipici dei linguaggi orientati agli oggetti che pongono maggiormente l'accento sui metodi rispetto alle funzioni. Il nome non deve necessariamente essere descrittivo come quello di un argomento di metodo, in quanto il suo ruolo è ovvio e non serve a scopi documentali.

Personalmente ho sempre usato "this" come identificatore perché "this" è al centro di ciò su cui sto lavorando quando scrivo e modifico la funzione. Sembra giusto e (almeno per me) ha senso.

Se il nome non deve essere descrittivo, il suo ruolo è ovvio e non ha scopi documentali , perché l'uso di "questo" dovrebbe essere disapprovato?

Dovremmo chiedere all'autore di quella guida di stile di sapere con certezza, ma penso che il motivo principale per cui sono d'accordo con lui è che la connessione tra struct e metodo è molto più libera in Go rispetto ad altre lingue .

In sostanza, quando scrivi un metodo come questo:

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

È quasi 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 variabile this/ self/ qualunque abbia in genere alcune proprietà speciali come essere fornita magicamente dalla lingua o avere un accesso speciale a metodi privati ​​(ricorda che Go non ha campi / metodi privati). Sebbene il "ricevitore" sia ancora in qualche modo "fornito magicamente", è così simile a un normale argomento di funzione che probabilmente non conta.

Inoltre, nei linguaggi OOP "tradizionali", tutti i metodi struct / class vengono forniti con la definizione di 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 (ovviamente nell'ambito del proprio codice).

Non ho scritto abbastanza Vai a creare la mia guida di stile, ma personalmente probabilmente userei thisnei metodi definiti nello stesso file della struttura che ricevono, e qualche nome del destinatario più descrittivo sui metodi che allego a strutture da altri file .

Non sono convinto da questo stile di guida e non credo che qualsiasi cosa è meglio di this, meo self. Perché this, meo selfrende libero eccellente che la variabile è un'istanza del contesto struct. Non sto dicendo che una variabile con un nome di struttura con caratteri minuscoli sia una cattiva idea, mi piace solo il modo in cui la thisrende super chiara.

Questo è da una prospettiva di JavaScript dove thisha un significato di parola chiave reale per il compilatore, ma dalla mia comprensione, se stanno bene con abbreviazioni di due lettere per il tipo di oggetto, dovrebbe essere abbastanza facile da usare invece. La ragione della differenza è che in un blocco abbastanza grande di codice asincrono progressivamente più profondo, potrebbe essere molto facile interpretare erroneamente cosa "questo", o il ricevitore, si trova in un contesto più profondo; ed è possibile che non sarà lo stesso oggetto.

In JavaScript, ad esempio, un modulo di controllo potrebbe avviare una finestra di dialogo e dichiarare una onLoadfunzione in linea per essa. Ma a quel punto, potrebbe essere molto facile per un altro programmatore interpretare erroneamente thisall'interno onLoadper fare riferimento al modulo di controllo, non alla finestra di dialogo; o vice versa. Ciò potrebbe essere evitato se il controllo fosse indicato come ctrle la finestra di dialogo come dg.