Penggunaan "ini" di Golang

Pada hal terdekat Golang memiliki panduan gaya yang ditemukan di sini , di bawah Nama Penerima ini tertulis:

Nama penerima metode harus mencerminkan identitasnya; sering singkatan satu atau dua huruf dari jenisnya mencukupi (seperti "c" atau "cl" untuk "Klien"). Jangan gunakan nama generik seperti "saya", "ini" atau "diri", pengidentifikasi khas bahasa berorientasi objek yang lebih menekankan pada metode dibandingkan dengan fungsi. Nama tidak perlu deskriptif seperti argumen metode, karena perannya jelas dan tidak melayani tujuan dokumenter.

Saya pribadi selalu menggunakan "ini" sebagai pengidentifikasi karena "ini" adalah fokus dari apa yang saya kerjakan ketika saya menulis dan mengedit fungsi. Kedengarannya benar, dan (setidaknya bagi saya) itu masuk akal.

Jika namanya tidak perlu deskriptif, perannya jelas, dan tidak ada gunanya dokumenter , mengapa penggunaan "ini" disukai?

Kami harus bertanya kepada penulis panduan gaya itu untuk mengetahui dengan pasti, tetapi saya pikir alasan utama saya agak setuju dengannya adalah bahwa hubungan antara struct dan metode jauh lebih longgar di Go daripada bahasa lain .

Intinya, ketika Anda menulis metode seperti ini:

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

Itu hampir persis sama dengan menulis fungsi seperti ini:

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

Satu-satunya perbedaan adalah sedikit perubahan sintaks dalam cara kita memanggil fungsi / metode.

Dalam bahasa lain variabel this/ self/ apa pun biasanya memiliki beberapa properti khusus seperti disediakan secara ajaib oleh bahasa tersebut, atau memiliki akses khusus ke metode pribadi (ingat Go tidak memiliki bidang / metode pribadi). Meskipun "penerima" masih "disediakan secara ajaib" sampai batas tertentu, itu sangat mirip dengan argumen fungsi biasa sehingga bisa dibilang tidak masuk hitungan.

Plus, dalam bahasa OOP "tradisional", metode struct / class 'semuanya datang dengan definisi struct / class, sehingga tidak ada lagi yang bisa ditambahkan dari luar. In Go, sejauh yang saya tahu ada yang bisa menambahkan lebih banyak metode untuk apa saja (dalam lingkup kode mereka sendiri, tentu saja).

Saya belum menulis cukup Pergi untuk membuat panduan gaya saya sendiri, tetapi secara pribadi saya mungkin akan menggunakan thismetode yang didefinisikan dalam file yang sama dengan struct yang mereka terima, dan beberapa nama penerima yang lebih deskriptif pada metode yang saya lampirkan ke struct dari file lain .

Saya tidak yakin dengan panduan gaya ini dan saya tidak berpikir ada yang lebih baik dari this, meatau self. Karena this, meatau selfmembuatnya sangat jelas bahwa variabel adalah turunan dari struct konteks. Saya tidak mengatakan variabel nama struct yang lebih rendah adalah ide yang buruk, saya hanya suka cara yang thismembuatnya sangat jelas.

Ini dari perspektif JavaScript di mana thismemiliki arti kata kunci yang sebenarnya untuk kompiler, tetapi dari pemahaman saya, jika mereka setuju dengan singkatan dua huruf untuk jenis objek, seharusnya cukup mudah untuk menggunakannya. Alasan perbedaannya adalah bahwa dalam blok kode asinkron yang semakin dalam dan besar, bisa sangat mudah untuk salah menafsirkan apa "ini", atau penerima, dalam konteks yang lebih dalam; dan mungkin itu tidak akan menjadi objek yang sama.

Dalam JavaScript misalnya, modul kontrol mungkin memulai dialog dan menyatakan onLoadfungsi sebaris untuknya. Tetapi pada titik itu, bisa sangat mudah bagi pembuat kode lain untuk salah menafsirkan thisdi dalam onLoaduntuk merujuk ke modul kontrol, bukan dialog; atau sebaliknya. Ini bisa dihindari jika kontrol disebut sebagai ctrldan dialog sebagai dg.