Użycie „tego” w Golang

Golang musi znaleźć przewodnik po stylu znajdujący się tutaj , w części Nazwy odbiorców napisane:

Nazwa odbiorcy metody powinna odzwierciedlać jej tożsamość; często wystarcza jedno- lub dwuliterowy skrót tego typu (np. „c” lub „cl” dla „Klient”). Nie używaj nazw ogólnych, takich jak „ja”, „to” lub „ja”, identyfikatory typowe dla języków zorientowanych obiektowo, które kładą większy nacisk na metody niż na funkcje. Nazwa nie musi być tak opisowa jak argument metody, ponieważ jej rola jest oczywista i nie służy dokumentowi.

Ja osobiście zawsze używałem „tego” jako identyfikatora, ponieważ „to” jest przedmiotem tego, nad czym pracuję, kiedy piszę i edytuję funkcję. Brzmi dobrze i (przynajmniej dla mnie) ma sens.

Jeśli nazwa nie musi być opisowa, to jej rola jest oczywista i nie służy żadnemu dokumentacyjnemu celowi , dlaczego używanie „tego” byłoby marne?

Musielibyśmy poprosić autora tego przewodnika po stylu, aby się upewnić, ale myślę, że głównym powodem, dla którego się z nim zgadzam, jest to, że związek między strukturą a metodą jest znacznie luźniejszy w Go niż w innych językach .

Zasadniczo, gdy piszesz taką metodę:

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

To prawie dokładnie to samo, co napisanie takiej funkcji:

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

Jedyną różnicą jest niewielka zmiana składni w sposobie wywoływania funkcji / metody.

W innych językach zmienna this/ self/ cokolwiek zwykle ma pewne specjalne właściwości, takie jak magiczne dostarczenie przez język lub specjalny dostęp do metod prywatnych (pamiętaj, że Go nie ma prywatnych pól / metod). Chociaż „odbiornik” jest do pewnego stopnia „dostarczany magicznie”, jest tak podobny do argumentu funkcji zwykłej, że prawdopodobnie się nie liczy.

Ponadto w „tradycyjnych” językach OOP wszystkie metody struct / class posiadają definicję struct / class, dzięki czemu nie można już dodawać z zewnątrz. W Go, o ile mi wiadomo, każdy może dodać więcej metod do czegokolwiek (oczywiście w ramach własnego kodu).

Nie napisałem wystarczająco dużo Go, aby stworzyć własny przewodnik po stylu, ale osobiście prawdopodobnie użyłbym thismetod zdefiniowanych w tym samym pliku, co otrzymywana przez nich struktura, oraz bardziej opisowej nazwy odbiorcy w metodach, które dołączam do struktur z innych plików .

Ten przewodnik po stylu nie przekonuje mnie i nie sądzę, że coś jest lepsze niż this, melub self. Ponieważ this, mealbo selfsprawia, że bardzo jasne, że zmienna jest instancją struktury kontekstowego. Nie twierdzę, że zmienna strukturalna o małych literach jest złym pomysłem, po prostu podoba mi się sposób, który thissprawia, że jest to bardzo jasne.

Jest to z punktu widzenia JavaScript, w którym thiskompilator ma rzeczywiste znaczenie słów kluczowych, ale z mojego zrozumienia, jeśli są one w porządku z dwuliterowymi skrótami dla typu obiektu, powinno być łatwo użyć tego zamiast tego. Powodem tej różnicy jest to, że w dość dużym bloku progresywnie głębszego kodu asynchronicznego bardzo łatwo byłoby źle zinterpretować, co „to” lub odbiornik znajduje się w głębszym kontekście; i możliwe, że nie będzie to ten sam obiekt.

Na przykład w JavaScript moduł sterujący może uruchomić okno dialogowe i zadeklarować onLoaddla niego funkcję wbudowaną. Ale w tym momencie inny koder może bardzo łatwo błędnie zinterpretować thiswnętrze, onLoadodnosząc się do modułu sterującego, a nie do okna dialogowego; lub odwrotnie. Można tego uniknąć, jeśli formant zostanie określony jako, ctrla okno dialogowe jako dg.