Uso de "esto" en Golang

En lo más cercano que tiene Golang a una guía de estilo que se encuentra aquí , en Nombres del receptor, esto está escrito:

El nombre del receptor de un método debe ser un reflejo de su identidad; a menudo una abreviatura de una o dos letras de este tipo es suficiente (como "c" o "cl" para "Cliente"). No utilice nombres genéricos como "yo", "esto" o "yo", identificadores típicos de lenguajes orientados a objetos que ponen más énfasis en los métodos que en las funciones. El nombre no tiene por qué ser tan descriptivo como el de un argumento de método, ya que su función es obvia y no tiene ningún propósito documental.

Personalmente, siempre he usado "this" como identificador porque "this" es el foco de mi trabajo cuando escribo y edito la función. Suena bien y (al menos para mí) tiene sentido.

Si el nombre no necesita ser descriptivo, su papel es obvio y no sirve para ningún propósito documental , ¿por qué el uso de "esto" estaría mal visto?

Tendríamos que preguntarle al autor de esa guía de estilo para saberlo con certeza, pero creo que la razón principal por la que estoy de acuerdo con él es que la conexión entre estructura y método es mucho más flexible en Go que en otros idiomas .

En esencia, cuando escribes un método como este:

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

Eso es casi exactamente lo mismo que escribir una función como esta:

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

La única diferencia es un ligero cambio de sintaxis en cómo llamamos a la función / método.

En otros idiomas, la variable this/ self/ whatever normalmente tiene algunas propiedades especiales, como ser proporcionada mágicamente por el lenguaje o tener acceso especial a métodos privados (recuerde que Go no tiene campos / métodos privados). Aunque el "receptor" todavía está siendo "provisto mágicamente" hasta cierto punto, es tan similar a un argumento de función regular que posiblemente no cuenta.

Además, en los lenguajes OOP "tradicionales", todos los métodos de struct / class vienen con la definición de struct / class, de modo que no se pueden agregar más desde afuera. En Go, hasta donde yo sé, cualquiera puede agregar más métodos a cualquier cosa (dentro del alcance de su propio código, por supuesto).

No he escrito suficiente Ir para hacer mi propia guía de estilo, pero personalmente probablemente lo usaría thisen métodos definidos en el mismo archivo que la estructura que reciben, y algún nombre de receptor más descriptivo en los métodos que adjunto a estructuras de otros archivos .

Esta guía de estilo no me convence y no creo que nada sea mejor que this, meo self. Porque this, meo selfdeja muy claro que la variable es una instancia de la estructura de contexto. No estoy diciendo que una variable de nombre de estructura en minúsculas sea una mala idea, solo me gusta la forma en que lo thisdeja súper claro.

Esto es desde una perspectiva de JavaScript donde thistiene un significado real de palabra clave para el compilador, pero según tengo entendido, si están de acuerdo con las abreviaturas de dos letras para el tipo de objeto, debería ser bastante fácil de usar. La razón de la diferencia es que en un bloque decentemente grande de código asincrónico progresivamente más profundo, podría ser muy fácil malinterpretar qué es "esto", o el receptor, en un contexto más profundo; y es posible que no sea el mismo objeto.

En JavaScript, por ejemplo, un módulo de control puede iniciar un diálogo y declarar una onLoadfunción en línea para él. Pero en ese punto, podría ser muy fácil para otro codificador malinterpretar el thisinterior onLoadpara referirse al módulo de control, no al diálogo; o viceversa. Esto podría evitarse si se hace referencia al control como ctrly al diálogo como dg.