Uso de "isto" em Golang

Na coisa mais próxima que Golang tem de um guia de estilos encontrado aqui , em Nomes de Receptores, está escrito:

O nome do destinatário de um método deve refletir sua identidade; geralmente é suficiente uma abreviação de uma ou duas letras do tipo (como "c" ou "cl" para "Cliente"). Não use nomes genéricos como "me", "this" ou "self", identificadores típicos de linguagens orientadas a objetos que dão mais ênfase aos métodos e não às funções. O nome não precisa ser tão descritivo quanto o de um argumento de método, pois seu papel é óbvio e não serve para nenhum propósito documental.

Pessoalmente, sempre usei "this" como identificador, porque "this" é o foco do trabalho em que escrevo e edito a função. Parece certo e (pelo menos para mim) faz sentido.

Se o nome não precisa ser descritivo, seu papel é óbvio e não serve para nenhum propósito documental , por que o uso de "isso" seria menosprezado?

Teríamos que pedir ao autor desse guia de estilo para ter certeza, mas acho que o principal motivo pelo qual concordo com ele é que a conexão entre struct e método é muito mais frouxa no Go do que em outros idiomas .

Em essência, quando você escreve um método como este:

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

Isso é quase exatamente a mesma coisa que escrever uma função como esta:

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

A única diferença é uma ligeira mudança de sintaxe na forma como chamamos a função / método.

Em outros idiomas, a variável this/ self/ qualquer que seja, normalmente possui algumas propriedades especiais, como magicamente fornecidas pelo idioma ou ter acesso especial a métodos privados (lembre-se de que o Go não possui campos / métodos privados). Embora o "receptor" ainda esteja sendo "fornecido magicamente" até certo ponto, é tão semelhante a um argumento de função regular que, sem dúvida, não conta.

Além disso, nas linguagens OOP "tradicionais", todos os métodos struct / class 'vêm com a definição struct / class, de forma que não mais podem ser adicionados de fora. No Go, até onde eu sei, alguém pode adicionar mais métodos a qualquer coisa (dentro do escopo de seu próprio código, é claro).

Ainda não escrevi o suficiente sobre Go para criar meu próprio guia de estilo, mas, pessoalmente, provavelmente usaria thismétodos definidos no mesmo arquivo que a estrutura que recebem e algum nome mais descritivo do receptor nos métodos que anexo às estruturas de outros arquivos. .

Não estou convencido por este guia de estilo e acho que nada é melhor do que this, meou self. Porque this, meou selfdeixa super claro que a variável é uma instância da estrutura de contexto. Não estou dizendo que uma variável de nome de estrutura com letras minúsculas é uma má idéia, apenas gosto da maneira que a thistorna super clara.

Isso é da perspectiva do JavaScript, onde thiso significado real da palavra-chave é para o compilador, mas, pelo que entendi, se estiverem de acordo com as abreviações de duas letras para o tipo de objeto, deve ser fácil usá-lo. A razão da diferença é que, em um bloco decentemente grande de código assíncrono progressivamente mais profundo, pode ser muito fácil interpretar mal o que "this", ou o receptor, está em um contexto mais profundo; e é possível que não seja o mesmo objeto.

Em JavaScript, por exemplo, um módulo de controle pode iniciar uma caixa de diálogo e declarar uma onLoadfunção embutida para ela. Mas, nesse ponto, poderia ser muito fácil para outro codificador interpretar mal o thisinterior onLoadpara se referir ao módulo de controle, não à caixa de diálogo; ou vice-versa. Isso poderia ser evitado se o controle fosse referido como ctrle a caixa de diálogo como dg.