Utilisation de «ceci» à Golang

Sur ce qui se rapproche le plus de Golang, un guide de style se trouve ici , sous Receiver Names, il est écrit:

Le nom du récepteur d'une méthode doit refléter son identité; souvent une abréviation d'une ou deux lettres de son type suffit (comme "c" ou "cl" pour "Client"). N'utilisez pas de noms génériques tels que "moi", "ceci" ou "soi", identificateurs typiques des langages orientés objet qui mettent davantage l'accent sur les méthodes que sur les fonctions. Le nom n'a pas besoin d'être aussi descriptif que celui d'un argument de méthode, car son rôle est évident et ne sert à rien de documentaire.

Personnellement, j'ai toujours utilisé "this" comme identifiant car "this" est au centre de ce sur quoi je travaille lorsque j'écris et édite la fonction. Cela semble juste et (pour moi au moins) cela a du sens.

Si le nom n'a pas besoin d'être descriptif, son rôle est évident et il ne sert à rien de documentaire , pourquoi l'utilisation de "ceci" serait-elle mal vue?

Nous devrions demander à l'auteur de ce guide de style de le savoir avec certitude, mais je pense que la principale raison pour laquelle je suis en quelque sorte d'accord avec lui est que la connexion entre struct et méthode est beaucoup plus lâche dans Go que dans d'autres langues .

En substance, lorsque vous écrivez une méthode comme celle-ci:

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

C'est presque exactement la même chose que d'écrire une fonction comme celle-ci:

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

La seule différence est un léger changement de syntaxe dans la façon dont nous appelons la fonction / méthode.

Dans d'autres langues, la variable this/ self/ quelle que soit la variable possède généralement des propriétés spéciales, comme être fournie magiquement par le langage ou avoir un accès spécial à des méthodes privées (rappelez-vous que Go n'a pas de champs / méthodes privés). Bien que le "récepteur" soit toujours "magiquement fourni" dans une certaine mesure, il est tellement similaire à un argument de fonction régulière qu'il ne compte sans doute pas.

De plus, dans les langages POO "traditionnels", les méthodes struct / classe sont toutes fournies avec la définition struct / class, de sorte qu'aucune autre ne peut être ajoutée de l'extérieur. Dans Go, pour autant que je sache, n'importe qui peut ajouter plus de méthodes à n'importe quoi (dans le cadre de son propre code, bien sûr).

Je n'ai pas assez écrit Go pour créer mon propre guide de style, mais personnellement, j'utiliserais probablement des thisméthodes définies dans le même fichier que la structure qu'ils reçoivent, et un nom de récepteur plus descriptif sur les méthodes que j'attache aux structures d'autres fichiers .

Je ne suis pas convaincu par ce guide de style et je ne pense pas que quelque chose soit meilleur que this, meou self. Parce que this, meou selfrend très clair que la variable est une instance de la structure de contexte. Je ne dis pas qu'une variable de nom de structure en casse inférieure est une mauvaise idée, j'aime juste la façon qui la thisrend super claire.

C'est du point de vue de JavaScript où thisle mot-clé a une signification réelle pour le compilateur, mais d'après ce que je comprends, s'ils acceptent les abréviations à deux lettres pour le type d'objet, il devrait être assez facile de l'utiliser à la place. La raison de la différence est que dans un bloc de code asynchrone de plus en plus profond, il pourrait être très facile de mal interpréter ce que "ceci", ou le récepteur, est dans un contexte plus profond; et il est possible que ce ne soit pas le même objet.

En JavaScript par exemple, un module de contrôle peut démarrer une boîte de dialogue et déclarer une onLoadfonction en ligne pour cela. Mais à ce stade, il pourrait être très facile pour un autre codeur de mal interpréter l' thisintérieur onLoadpour se référer au module de contrôle, pas au dialogue; ou vice versa. Cela pourrait être évité si le contrôle était appelé ctrlet la boîte de dialogue dg.