Использование «этого» на Голанге

На ближайшей вещи Golang имеет к руководству по стилю нашла здесь , под ресивером имен это написано:

Имя получателя метода должно отражать его идентичность; часто достаточно одной или двух буквенных аббревиатур этого типа (например, «c» или «cl» для «Client»). Не используйте универсальные имена, такие как «я», «это» или «я», идентификаторы, типичные для объектно-ориентированных языков, в которых больше внимания уделяется методам, а не функциям. Имя не обязательно должно быть таким же описательным, как и у аргумента метода, так как его роль очевидна и не имеет никакой документальной цели.

Лично я всегда использовал «this» в качестве идентификатора, потому что «this» - это то, над чем я работаю, когда пишу и редактирую функцию. Это звучит правильно, и (по крайней мере для меня) это имеет смысл.

Если имя не обязательно должно быть описательным, его роль очевидна и не имеет никакой документальной цели , с какой стати следует осуждать использование «этого»?

Мы должны были бы попросить автора этого руководства по стилю знать наверняка, но я думаю, что главная причина, по которой я с ним согласен, заключается в том, что связь между struct и method гораздо более слабая в Go, чем в других языках .

По сути, когда вы пишете такой метод:

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

Это почти то же самое, что написать такую ​​функцию:

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

Единственная разница - небольшое изменение синтаксиса в том, как мы вызываем функцию / метод.

В других языках this/ self/ любая переменная обычно имеет некоторые специальные свойства, такие как магическое предоставление языка или специальный доступ к закрытым методам (помните, что у Go нет закрытых полей / методов). Хотя «получатель» все еще «магически предоставляется» в некоторой степени, он настолько похож на аргумент обычной функции, что, вероятно, не считается.

Кроме того, в «традиционных» языках ООП все методы struct / class поставляются с определением struct / class, так что больше нельзя добавлять извне. Насколько мне известно, в Go каждый может добавить больше методов к чему угодно (конечно, в рамках своего собственного кода).

Я не написал достаточно Go, чтобы создать свое собственное руководство по стилю, но лично я, вероятно, использовал бы thisметоды, определенные в том же файле, что и получаемая им структура, и более описательное имя получателя для методов, которые я прикрепляю к структурам из других файлов ,

Я не убежден в этом стиль руководства , и я не думаю , что это лучше , чем this, meили self. Потому что this, meили selfпроясняет, что переменная является экземпляром структуры контекста. Я не говорю, что переменная структурного имени в нижнем регистре - плохая идея, мне просто нравится способ, который thisделает это супер ясным.

Это с точки зрения JavaScript, где thisфактическое ключевое слово имеет значение для компилятора, но, насколько я понимаю, если они в порядке с двухбуквенными аббревиатурами для типа объекта, его должно быть достаточно просто использовать вместо этого. Причина различия заключается в том, что в прилично большом блоке постепенно более глубокого асинхронного кода может быть очень легко неверно истолковать, что означает «это» или получатель, в более глубоком контексте; и возможно это не будет тот же объект.

Например, в JavaScript модуль управления может запустить диалог и объявить onLoadдля него встроенную функцию. Но в этот момент другому кодировщику может быть очень легко неправильно интерпретировать thisвнутреннюю часть, onLoadссылаясь на модуль управления, а не на диалог; или наоборот. Этого можно было бы избежать, если бы элемент управления упоминался как, ctrlа диалог - как dg.