Godot: Variabel atau fungsi pribadi di GDScript

Hal terdekat untuk variabel adalah menggunakan setget untuk mengarahkan ke fungsi yang tidak melakukan apa pun atau mencetak peringatan. Tapi tidak, tidak ada variabel atau fungsi pribadi yang sebenarnya.

@YeldhamDev Sayangnya, setget sangat membantu tetapi jika Anda tidak ingin melihat properti publik - tidak ada cara untuk melakukan ini. Itu buruk, @reduz bagaimana menurutmu?

Itu juga tidak mungkin dengan Python: bahkan garis bawah ganda di depan tidak mencegah Anda mengakses dan memodifikasi variabel. Dalam Python Anda menggunakan konvensi sebagai gantinya: satu garis bawah utama untuk menunjukkan variabel adalah pribadi, ALL_CAPS untuk menunjukkan sesuatu adalah konstan ... mereka masih dapat diakses dari mana saja tetapi dalam praktiknya itu bukan masalah.

@NathanLovato Mungkin GDScript harus berbeda dari Python dalam kasus itu?

@Chaosus Anda harus memberikan argumen untuk menjelaskan mengapa variabel pribadi diperlukan. Kalau tidak, tidak mungkin seseorang akan mengerjakan ini.

Variabel pribadi ada di sini untuk membantu merangkum data dan mencegah penggabungan dengan kelas lain - ini mencegah kelas lain mengakses variabel ini. Jika Anda tidak mengaksesnya sejak awal, masalahnya juga terpecahkan.

Dalam kedua kasus - menggunakan kata kunci pribadi atau menulis menggunakan konvensi - Anda harus mempelajari kapan dan bagaimana membuat variabel menjadi pribadi, kapan dan bagaimana Anda dapat mengaksesnya. Anda harus belajar mendesain kelas Anda sehingga Anda dapat mengubah internal nanti tanpa merusak antarmuka mereka dan sebaliknya. Saya pikir itu sumber masalah terbesar Anda dalam hal arsitektur kode.

Mengenai Python, ini berfungsi untuk jutaan pengembang Python. Ada mekanisme untuk membuat variabel "pribadi", yang mencegah akses langsung, dan itu sederhana: tulis dua garis bawah utama, bukan satu. Tapi saya belum melihat seseorang menggunakannya. Itu belum tersedia di JS sampai saat ini juga. Mungkin ada bahasa lain seperti itu.

Saya tidak mengatakan itu tidak boleh di GDscript - saya benar-benar tidak keberatan jika orang lain menggunakan fitur ini dengan baik. Saya hanya tidak yakin itu berguna. Misalnya Godot tidak bisa membuat daftar variabel dengan _ atau dua utama dalam pelengkapan otomatis (walaupun ia menggunakan _function_name sebagai konvensi untuk fungsi virtual)?

Saya hanya tidak ingin melihat metode internal dengan intellisense di GDScript, dan membuatnya lebih seperti C # dan bahasa yang diketik statis lainnya

Ya, saya setuju itu sulit untuk diterapkan dan membutuhkan kata kunci baru, terlalu banyak usaha untuk hasil yang sangat kecil
Solusi dengan awalan "__" sebagian memecahkan masalah, terima kasih, (Saya tidak pernah bekerja dengan Python jadi ini sesuatu yang baru bagi saya).

Saya tahu ini sudah ditutup dan diarsipkan (tidak yakin apakah harus ada masalah lain yang dibuka untuk ini), tetapi pengubah akses adalah fitur yang cukup penting dalam bahasa pemrograman apa pun. Jika saya ingin membuat addon Node baru untuk Godot dan node baru saya memiliki variabel status internal yang tidak boleh dimodifikasi di luar Node, tidak ada yang mencegah hal itu terjadi. Saya mengerti bahwa Anda dapat menggunakan garis bawah utama untuk meniru fitur ini, tetapi tetap tidak mencegah akses yang merupakan inti dari pengubah akses. Menurut pendapat saya ini adalah masalah yang cukup besar karena tidak ada cara untuk mengontrol cara orang lain berinteraksi dengan objek Anda.

Ya saya setuju dengan @dylmeadows itu akan berguna dengan cara ini

Saya pasti pro fungsi dan variabel pribadi juga.

1. Ya, kami memiliki konvensi untuk pribadi menggunakan _ di depan nama metode TAPI konvensi yang sama digunakan untuk fungsi virtual. Jadi jika saya melihat garis bawah, itu bisa berarti "tidak pernah menyentuh fungsi itu!" atau "timpa fungsi itu!". Itu sangat berbahaya, jujur.

2. Jika saya bekerja sendiri atau dalam tim yang sangat kecil pada proyek kecil, itu tidak terlalu berat karena saya tahu fungsi apa yang dimaksudkan untuk digunakan dan fungsi apa yang hanya untuk penggunaan internal.
   Tetapi dengan tim yang berkembang, ini menjadi semakin sulit. Orang-orang bekerja dengan kelas yang tidak mereka tulis sendiri sepanjang waktu dan saya karena saya adalah orang yang menulis banyak fungsi internal kecil untuk membuat semuanya berfungsi, saya benar-benar ingin dapat mencegah orang memanggil fungsi-fungsi ini, karena jika mereka menggunakan yang mungkin menyebabkan perilaku dan bug yang tidak disengaja dan membutuhkan waktu untuk memperbaiki hal-hal ini setelah kesalahan dilakukan. Dan terlepas dari kesepakatan umum, hal-hal ini akan terjadi dalam tim yang lebih besar, karena bagaimanapun juga mereka dapat dipanggil dari luar.

3. Terakhir, tetapi tidak kalah penting; penyelesaian otomatis. Saya adalah seseorang yang sering menggunakan ini untuk mempelajari apa yang dapat dilakukan kelas.
   Saya hanya menempatkan '.' di akhir dan lihat fungsi apa yang muncul. Jika sesuatu terdengar berguna, saya menggunakannya.
   Akan jauh lebih bersih jika tidak berantakan dengan semua fungsi yang tidak seharusnya dipanggil. Selain itu - dan lagi - saya masih tidak tahu apakah fungsi _name ini pribadi atau virtual.

Juga, variabel pribadi bahkan dapat berguna pada proyek pribadi. Terkadang ada periode waktu saya tidak dapat mengerjakan game yang sedang saya kerjakan, jadi saya mulai melupakan apa yang dilakukan beberapa fungsi saya. Atau, saya lupa mana yang harus dan tidak boleh saya gunakan.

Variabel pribadi akan sangat bagus dengan ini! Itu akan memastikan bahwa variabel atau fungsi tidak dapat diakses di luar Node, dan ketika saya kembali ke proyek, saya bisa menebak bagaimana menggunakan variabel dan tidak perlu membaca semua kode saya sepenuhnya lagi.

Saya mendukung apa yang dikatakan Byteron dan dylmeadows juga. Mereka hanya menulis posting mereka dengan cukup baik dan mengatakan dengan tepat apa yang saya pikirkan. Hanya ingin menambahkan dua sen saya.

Saya akan membuka kembali karena beberapa pengguna tertarik dan ingin membahas ini. Masih belum direncanakan, tapi kita bisa berdiskusi dan melihat apakah ada minat yang kuat di masyarakat.

Python bukan bahasa terbaik yang disebut ideal.
Telah dinyatakan bahwa Godot sangat berorientasi objek. Setiap skrip adalah objek juga. Salah satu prinsip utama pemrograman berorientasi objek adalah menyediakan enkapsulasi. jika saya ingin memiliki sesuatu yang tidak tersentuh dari luar, itu mungkin untuk alasan terbaik.

Saya pribadi tidak pernah menemukan waktu di mana saya benar-benar perlu mencegah orang mengedit variabel atau mengakses suatu fungsi. Setiap kali saya ingin memberi tahu orang-orang untuk tidak mengacaukan sesuatu kecuali mereka tahu apa yang mereka lakukan, saya mengawali namanya dengan _ (atau _internal_ atau serupa).

Saya tidak akan keberatan dengan kata kunci (atau serupa) yang hanya akan menyembunyikan variabel/fungsi dari pelengkapan otomatis. Saya hanya tidak berpikir mencegah akses sepenuhnya diperlukan.

Di satu sisi, lebih baik memperingatkan, bukan melarang. Tetapi di sisi lain, bidang dan metode pribadi biasanya digunakan berkali-kali. Dan nama variabel yang panjang (misalnya _internal_variable ) agak mengganggu.
Bagaimanapun, keberadaan kata kunci private tidak memaksa Anda untuk menggunakannya.

Anggota pribadi kelas untuk sesuatu seperti konstanta. Demikian pula, kita dapat menulis nama variabel dalam HURUF BESAR dan setuju bahwa kita tidak akan mengubah nilainya. Tapi kita tidak melakukan itu, bukan? Artinya, variabel privat merupakan persilangan antara variabel biasa dan konstanta. Mengapa tidak memasukkan kata kunci khusus untuk kasus ini?

Ya, kami memiliki konvensi untuk pribadi menggunakan _ di depan nama metode TAPI konvensi yang sama digunakan untuk fungsi virtual. Jadi jika saya melihat garis bawah, itu bisa berarti "tidak pernah menyentuh fungsi itu!" atau "timpa fungsi itu!". Itu sangat berbahaya, jujur.

Itu masalah terbesar yang saya lihat di sini. Alih-alih kata kunci private , mungkin kita bisa memiliki kata kunci virtual ? Beberapa metode virtual sudah muncul dalam pelengkapan otomatis saat Anda menulis "func", jadi kata kunci untuk membedakan secara eksplisit antara fungsi virtual yang seharusnya Anda timpa dan fungsi pribadi yang seharusnya tidak muncul dalam pelengkapan otomatis sudah cukup. Manfaat kata kunci virtual adalah Anda akan menggunakannya lebih jarang daripada private , jadi lebih sedikit penulisan.

Saya akan senang melihat anggota kelas privat juga disertakan. Ada alasan mengapa ini ada dalam bahasa lain. Konsumen/anggota tim lain (atau bahkan Anda sendiri) tidak perlu mengetahui cara kerja setiap kelas. Bahkan, mereka mungkin seharusnya tidak memiliki pilihan untuk bermain-main dengan fungsionalitas yang seharusnya bersifat internal.

Saya mengerti bahwa garis bawah utama harus "menunjukkan" bahwa ini adalah anggota pribadi, tetapi dalam praktiknya tidak ada yang peduli jika entah bagaimana memodifikasinya menyelesaikan pekerjaan. Ini sangat menyakitkan jika Anda ingin menggunakannya sebagai plugin dan semua orang dapat mengubah apa pun yang mereka inginkan. Saya ingin memiliki kontrol penuh atas keadaan objek/skrip yang saya buat. Memiliki objek yang dapat mengubah aspek apa pun dari statusnya kapan pun seseorang ingin melakukannya membuat kode yang dapat dikonsumsi orang lain lebih dari sekadar menjengkelkan.

Selain semua itu, akan sangat bagus untuk mendeklarasikan daftar variabel/fungsi yang "tersedia".

Bisakah saya membuat satu rekomendasi untuk tim Dev lalu tolong pertimbangkan semua ini? Ubah urutan daftar Pelengkapan Otomatis. Setiap var atau func yang tidak dimulai dengan huruf atau angka muncul di __Bottom__ daftar pelengkapan otomatis. Maka Anda cukup banyak harus mengetik _ untuk melihat item Selain itu akan lebih baik jika kita bisa menggunakan simbol non-matematika atau logika lainnya dalam nama? Belum mencobanya tetapi apakah €Display atau Print menjadi nama fungsi yang dapat diterima? Dll.

Selain itu, alangkah baiknya jika kita bisa menggunakan simbol non-matematika atau logika lainnya dalam nama? Belum mencobanya tetapi apakah €Display atau Print menjadi nama fungsi yang dapat diterima? Dll.

Lihat https://github.com/godotengine/godot/issues/24785.

Jadi, Setelah mengutak-atik ini, saya sampai pada kesimpulan bahwa jika Anda mendefinisikan setter yang tidak melakukan apa-apa, bahkan jika Anda mencoba menetapkan nilai baru ke variabel yang sama dalam skrip yang berbeda dan mencoba mencetaknya, nilai aslinya akan menjadi dicetak. Ini tidak terlalu pribadi, tapi saya rasa itu cukup dekat...

artinya tidak ada petunjuk apa pun bahwa variabel yang tampaknya bersifat publik dan Anda baru saja dimodifikasi tidak diubah?
selamat bersenang-senang kode debug yang menggunakan metode ini secara ekstensif.

Alih-alih penyetel kosong, Anda juga dapat mencetak kesalahan.

Saya masih hanya tahu bahwa saya telah melakukan sesuatu yang seharusnya tidak saya lakukan setelah saya menjalankan program dan benar-benar mencapai baris kode itu. Tampaknya masih bersifat publik saat menulis kode dan masih memerlukan beberapa baris kode untuk menyiapkan satu variabel pribadi.
Menempatkan private di depan variabel itu jauh lebih pendek, tidak memerlukan baris kode tambahan dan akan menghentikan saya untuk mengaksesnya secara salah saat saya mengetiknya.

GDScript terasa cukup C++-ish bagi saya terlepas dari kenyataan bahwa itu adalah bahasa yang dinamis. Ketika saya beralih dari menulis kode dalam C++ ke GDScript, saya merindukan pengubah akses itu. Karena itu, GDScript memang kehilangan dukungan penuh untuk OOP.

Saya hanya membaca sepintas masalah ini, tetapi alangkah baiknya jika setidaknya dapat menyembunyikan fungsi dan variabel dari pelengkapan otomatis jika namanya diawali dengan garis bawah. Saya kira masalah utama dengan itu adalah menentukan apakah itu fungsi virtual dan karena itu mungkin akan muncul terlepas

Masalahnya adalah bahwa garis bawah juga digunakan untuk fungsi virtual, dan tentu saja ada kasus di mana Anda ingin fungsi virtual menjadi publik juga.

Mungkin menyembunyikan fungsi awalan garis bawah dari node/objek lain saja, tetapi tunjukkan untuk panggilan pada diri/basis.

Saran saya adalah menggunakan garis bawah tunggal untuk fungsi virtual dan garis bawah ganda di depan untuk fungsi "pribadi". Dengan cara ini kita dapat menyembunyikannya dari pelengkapan otomatis tanpa mempengaruhi fungsi virtual.

Menggunakan garis bawah untuk menyembunyikan variabel itu buruk karena ketika Anda mengubah akses _attribute_ variabel, Anda harus mengubah _name_-nya. Faktanya, variable dan _variable adalah nama yang berbeda.
Ini juga seperti titik dalam nama file UNIX: keputusan yang cukup kontroversial.

Berikut pendapat saya

• Awalan dengan "__" untuk fungsi pribadi
• Fungsi dengan "__" tidak muncul di pelengkapan otomatis
• "fungsi pribadi x()" adalah gula sintaksis untuk "fungsi __x()"

Di atas memecah kode apa pun yang menyertakan variabel yang diawali dengan "__". Tapi, tidak termasuk itu, saya pikir sistem itu ideal.

Fitur GDScript sejauh ini sangat mirip dengan Python/JS, dan kedua bahasa ini tidak memiliki variabel dan fungsi pribadi untuk alasan yang sangat bagus - ini adalah kebalikan lengkap dari filosofi desain mereka. Anda memiliki kebebasan, dan kebebasan itu penting, itulah yang membuatnya mudah untuk dikodekan. Anda mengorbankan enkapsulasi, tapi itulah filosofi mereka. Enkapsulasi yang sebenarnya sudah rusak tanpa pemeriksaan jenis [Kecuali Anda memeriksa semua jenis sendiri, yang kemungkinan besar tidak akan Anda lakukan]. Jadi, kecuali mereka menerapkan pengetikan yang ketat, variabel pribadi terasa salah. Dalam gradien OOP, pengetikan ketat dilakukan sebelum variabel pribadi. Ada banyak bahasa dengan pengetikan ketat tetapi tidak ada variabel pribadi, tetapi saya tidak tahu bahasa apa pun dengan variabel pribadi dan tidak ada pengetikan ketat. Ini sekali lagi, untuk alasan yang bagus. Di luar itu, JS bahkan memberi Anda akses ke seluruh pohon warisan dan memungkinkan Anda mengubah aspek-aspek itu juga. Anda dapat mengubah kelas apa yang diwarisi objek selama runtime, dengan kode apa pun yang memiliki objek Anda! Tentu saja, itu tidak terjadi, tetapi menunjukkan filosofi desain.

Jadi, menurut saya, variabel pribadi yang sebenarnya akan secara drastis menghambat bahasa. Bagaimanapun, saya pikir sistem Python melakukannya dengan baik, Anda memiliki __ yang dapat Anda gunakan untuk mengakses variabel pribadi, tetapi memperjelas bahwa Anda mengacaukan sesuatu internal, namun itu tidak membatasi Anda secara berarti. Siapa pun yang menginginkan filosofi desain OOP sejati tidak akan pernah bisa menggunakan "__", atau memilikinya dalam gaya pengkodean perusahaan atau proyek mereka. Mungkin opsi untuk menandainya sebagai kesalahan akan menyenangkan. Maksud saya secara umum pengetikan bebek dan variabel pribadi tidak benar-benar cocok. Minimal Anda benar-benar mengacaukan namespace karena sekarang apa, obj.set("hai", 5) tidak berfungsi jika "hai" bersifat pribadi? Tetapi apakah itu berhasil jika "hai" tidak ada? Itu tidak masuk akal... Jadi, sangat kuat tidak untuk memaksa swasta untuk benar-benar tidak dapat diakses tidak peduli apa yang Anda lakukan, itu adalah suara saya. Sangat kuat ya untuk variabel pribadi ada seperti yang dilakukan Python saat ini. Tbh Saya masih tidak yakin bagaimana menyelesaikan masalah pengetikan bebek dengan variabel pribadi, meskipun keinginannya adalah untuk memiliki variabel pribadi yang benar-benar dan tidak dapat diakses. Saya kira Anda hanya memblokir obj.set dan membuatnya membuat kesalahan. Sekarang obj.set perlu mengembalikan boolean sepertinya, yang aneh. Panggilan is_private? Bahwa Anda harus menelepon sebelum setiap penggunaan obj.set? tidak tahu

[Ya Tuhan, bisakah kita benar-benar mendapatkan deteksi kesalahan yang sebenarnya, kita sedang berbicara tentang variabel pribadi tetapi untuk saat ini jika Anda memiliki bug di gdscript, permainan akan mengabaikannya secara diam-diam (facepalm). Mungkin saya salah melakukannya, tetapi jika ada kode saya yang melakukan sesuatu yang ilegal, gdscript tampaknya hanya mengembalikan null dari fungsinya, yang membuatnya sangat sulit untuk dilacak, JS pernah seburuk itu dan JS adalah bahasa yang berantakan. Saya tahu menerjang permainan mungkin terlalu banyak, tetapi saya tetap harus hanya mencari biner basis kode saya dengan meletakkan pernyataan cetak sampai saya menemukan dua pernyataan cetak berturut-turut di mana yang pertama dicetak dan yang terakhir tidak, hanya untuk mencari tahu di mana kode tersebut rusak. JS/Python secara mengejutkan jauh lebih ketat dalam hal itu, terlepas dari betapa bebasnya mereka dalam hal lain.]

Saya menyarankan untuk menemukan organisasi proyek yang konsisten untuk meminimalkan masalah. Anda dapat menggunakan simpul akar adegan sebagai antarmuka untuk mengontrol adegan dari luar dan skrip anak sebagai backend.

Atau Anda hanya dapat menggunakan metode, mengekspor vars, dan sinyal, dan tidak pernah menyentuh variabel sederhana dari luar. Itu adalah konvensi sederhana dan GDScript dapat menjaga kesederhanaannya.

Itu juga tidak mungkin dengan Python: bahkan garis bawah ganda di depan tidak mencegah Anda mengakses dan memodifikasi variabel. Dalam Python Anda menggunakan konvensi sebagai gantinya: satu garis bawah utama untuk menunjukkan variabel adalah pribadi, ALL_CAPS untuk menunjukkan sesuatu adalah konstan ... mereka masih dapat diakses dari mana saja tetapi dalam praktiknya itu bukan masalah.

Saya hanya ingin mengatakan, bahwa adalah mungkin untuk memiliki atribut _private_ di Python.

Kutipan (https://www.python.org/dev/peps/pep-0008/):

__double_leading_underscore: saat menamai atribut kelas, memanggil name mangling (di dalam kelas FooBar, __boo menjadi _FooBar__boo; lihat di bawah).

__double_leading_and_trailing_underscore__: objek atau atribut "ajaib" yang hidup di ruang nama yang dikontrol pengguna. Misalnya __init__, __import__ atau __file__. Jangan pernah menemukan nama seperti itu; hanya gunakan seperti yang didokumentasikan

Jika Anda mengklik tautan itu dan CTRL + F "pribadi" Anda akan mendapatkan

Kami tidak menggunakan istilah "pribadi" di sini, karena tidak ada atribut yang benar-benar pribadi di Python (tanpa jumlah pekerjaan yang umumnya tidak perlu).

Variabel garis bawah ganda atau garis bawah tunggal bertindak seperti variabel normal, itu hanya konvensi untuk referensi bahwa mereka tidak boleh digunakan dan dapat berubah ketika Anda memperbarui perpustakaan karena mereka internal. Secara umum, karena bahasa pythonic seperti GDScript memperlakukan objek seolah-olah mereka hanya kamus, akan canggung untuk mencoba memaksa variabel pribadi dan membuatnya menggunakan namespace.

Jika Anda mengklik tautan itu dan CTRL + F "pribadi" Anda akan mendapatkan

Kami tidak menggunakan istilah "pribadi" di sini, karena tidak ada atribut yang benar-benar pribadi di Python (tanpa jumlah pekerjaan yang umumnya tidak perlu).

Variabel garis bawah ganda atau garis bawah tunggal bertindak seperti variabel normal, itu hanya konvensi untuk referensi bahwa mereka tidak boleh digunakan dan dapat berubah ketika Anda memperbarui perpustakaan karena mereka internal. Secara umum, karena bahasa pythonic seperti GDScript memperlakukan objek seolah-olah mereka hanya kamus, akan canggung untuk mencoba memaksa variabel pribadi dan membuatnya menggunakan namespace.

Saya setuju, mereka tidak menyebutnya atribut _private_. Namun izinkan saya menjelaskan cara kerjanya:

# defining class Employee
class Employee:
    def __init__(self, name, salary):
        self.name = name
        self.__salary = salary

>>> emp = Employee("Bill", 10000)
>>> emp.__salary
# AttributeError: 'employee' object has no attribute '__salary'

Jadi itu tidak disebut atribut _private_, tetapi berperilaku hampir seperti itu.
Akan sangat bagus untuk memiliki atribut yang hampir pribadi di GDScript seperti yang ada di Python.

Oh ya, saya sangat setuju dengan Anda. Python hanya memberi Anda gula sintaksis untuk menggunakan ._Employee__salary. Saya pribadi tidak suka cara python melakukannya dan saya pikir itu bisa sangat ditingkatkan di Godot, seperti yang saya sebutkan di komentar saya,

class Employee:
      var name # normal
      private var salary # Syntactic sugar for var _salary

Yang lebih bersih karena _Employee__salary adalah cara yang buruk untuk menyembunyikan nama variabel, dan memiliki kata kunci pribadi membuatnya seperti OOP biasa. Lebih baik lagi, ini memblokir kemampuan untuk memiliki gaji variabel publik dan variabel pribadi _gaji, yang akan jelek dan seharusnya menjadi kesalahan sintaks seperti di Jawa. Ini karena keduanya akan dinyatakan "gaji var" dan "gaji var pribadi", konflik yang jelas. Cara lain untuk dipikirkan adalah "Untuk mengakses variabel pribadi dari beberapa kelas C lain dengan anggota m, Anda harus menggunakan garis bawah seperti pada C._m". Kita kemudian bisa membuat kesalahan untuk mendeklarasikan variabel yang dimulai dengan garis bawah, yaitu menjadikan private satu-satunya cara untuk mendeklarasikannya, sehingga jelas apa yang sedang dilakukan.

Saya pikir satu-satunya alasan mengapa python memiliki situasi yang kurang diinginkan seperti rn adalah karena tidak ada deklarasi di bagian atas untuk variabel, Anda hanya membuat variabel kelas di salah satu badan fungsi. GDScript tampaknya memerlukan deklarasi di badan kelas, memberikan segue mudah ke dalam deklarasi pribadi seperti Java.

Saya tidak suka memiliki kata kunci yang bertindak sebagai gula sintaks kecuali mereka menghemat banyak pengetikan. Di sini, mengetik private sebenarnya akan membuat Anda menulis lebih banyak karakter, yang menjadikannya anti-shortcut :slightly_smiling_face:

Juga, bagaimana dengan metode? Beberapa metode virtual dimulai dengan garis bawah, jadi kami tidak dapat menggunakan satu garis bawah untuk menandainya sebagai pribadi. Kita bisa menggunakan dua garis bawah, yang akan menghindari konflik dengan mengorbankan menjadi lebih lama. Saya juga menyukai gagasan untuk mengikuti konvensi Python ketika masuk akal – "dunder" telah populer untuk sementara waktu dalam bahasa itu.

Saya tidak berpikir maksudnya adalah agar itu dilihat sebagai jalan pintas, alih-alih idenya adalah di luar kelas, Anda menggunakan "_" untuk mengakses variabel pribadi. Gula sintaksis adalah bagaimana penerapannya. Pada dasarnya identik dengan bagaimana python melakukannya. Tapi seperti ya itu benar, dalam kasus python sintaks gula menghemat banyak pengetikan, tapi itu hanya karena alias menjadi sesuatu yang panjang. Aliasing menjadi sesuatu yang lebih pendek benar-benar lebih baik, jadi memiliki alias yang lebih pendek dan kemudian memilih untuk tidak memiliki sintaks gula karena alias terlalu pendek, hanya bermuara pada apakah kita harus mendukung variabel pribadi sama sekali; kita tidak harus melakukannya, kita bisa meminta pengguna menambahkan variabel dengan garis bawah atau memilih konvensi mereka sendiri. Ini hanya untuk orang-orang yang berpikiran Java dan C++, yang lebih suka menulis "private var myvariable" daripada hanya menganggap "_myvariable" sebagai private sebagai konvensi, yang terasa aneh ketika datang dari dunia OOP, bahkan jika mereka berdua mencapai yang tepat hal yang sama. Garis bawah ganda akan cocok dengan sintaks Python dengan cukup baik, jadi saya juga siap untuk yang itu, terutama jika _ bertentangan dengan hal-hal lain

Saya lebih suka memiliki kata kunci yang secara eksplisit mendefinisikan perilaku di luar apa yang dapat disalahartikan hanya sebagai konvensi gaya. private mendapatkan suara saya.

Menambahkan api ke diskusi: konvensi penataan python untuk anggota "pribadi" adalah menambahkan garis bawah sebelum nama, yang _sudah_ digunakan oleh gdscript untuk tujuan berbeda dalam metode acara umum seperti _ready() , _input , dan _physics_process , untuk beberapa nama. Apakah itu seharusnya pribadi? Bagaimana menambahkan kata kunci pribadi berinteraksi dengan metode ini? Apakah kata kunci lain seperti protected juga perlu diterapkan?

Bagaimanapun, saya setuju untuk menegakkan arahan restriktif _by design_ daripada hanya membiarkan pengguna menentukan konvensi. Tetapi saya tidak begitu yakin anggota kelas privat akan memberikan peningkatan yang dimaksudkan mengingat kompleksitas implementasi. Seluruh API harus ditinjau kembali juga, saya kira. Seluruh bahasa akan memiliki paradigma yang sama sekali berbeda.

Ya, seseorang sudah mencatat itu. (Lihat tanggapan Calinou) Garis bawah ganda akan menjadi cara yang tepat. Sama seperti Python juga.

2c saya. Dalam Python tidak ada yang mencegah siapa pun untuk mengakses anggota kelas yang dimulai dengan _ , dan dengan beberapa pengetahuan internal dengan __ juga.

Ini semua tentang menunjukkan niat. Filosofinya adalah bahwa kita semua adalah orang dewasa, kita dapat membuat keputusan apakah kita benar-benar perlu mengakses variabel atau fungsi yang dianggap privat. Dan jika kita melakukan itu, kita sendiri yang menanggung konsekuensinya.

@sanchopanca

1. GDScript bukan Python.
2. Mengikuti logika Anda, konstanta juga tidak diperlukan (var CONSTANT = 1).
3. Tidak semua orang suka menggunakan __ .

Saya untuk kata kunci private , bahkan tidak akan merusak kompatibilitas.
Alih-alih, menjadikan func dan var pribadi dengan menggunakan _ , akan mengubah beberapa hal untuk menggunakannya karena alasan lain (saya menggunakan _ hanya dalam parameter fungsi ).

Ini mengingatkan saya pada fitur pengetikan statis baru dan fitur pribadi dan virtual ini akan berjalan dengan cara yang sama.
Ini akan memberikan basis kode yang lebih jelas, dengan deteksi kesalahan yang lebih baik, pelengkapan otomatis yang lebih baik, dan juga dokumentasi kode secara otomatis.
Jika seseorang membaca kode Anda, mereka akan lebih memahami apa fungsinya.

Saya bertanya-tanya seberapa sulit menerapkan dua kata kunci baru untuk tim pengembang.
Ini akan jauh lebih mudah daripada sistem pengetikan pasti dan akan memberikan banyak nilai.
Jika seseorang dari tim pengembang dapat memberi saya petunjuk tentang apa yang harus dilakukan, saya akan dengan senang hati membantu untuk jujur!

Hanya untuk menambahkan satu suara lagi untuk menambahkan kata kunci pribadi dan dilindungi.
Jika Anda pernah menulis kode yang akan digunakan oleh pengembang lain, Anda tidak boleh menentangnya.
Semua yang menentang penambahan kata kunci dapat memeriksa topik ini:
https://softwareengineering.stackexchange.com/questions/143736/why-do-we-need-private-variables

Kami masih akan menggunakan GDscript tetapi mengapa tidak membuatnya lebih baik dalam prosesnya.

_, __, ___, dan seterusnya sangat bodoh seperti menambahkan awalan ke nama variabel untuk menyarankan tipe
intAge, strName, bIsAlive... semua ini hanya menunjukkan fitur bahasa yang hilang.
Jadi, bahkan tanpa membandingkan GDScript dengan Python atau bahasa lain, pengembang dapat menjalankan polling untuk melihat apakah mayoritas menginginkan atau tidak menginginkan kedua kata kunci ini;)

Jika fitur tersebut diimplementasikan, saya berharap cara C++ yang akan dipilih. Kata kunci "pribadi" atau "publik" di depan setiap deklarasi membuat C# rumit untuk dibaca.

Saya pribadi tidak akan menyukai cara C++, karena kami tidak memiliki sintaks pengetikan C++ dan semuanya akan menjadi publik secara default. saya akan menghargai kemampuan untuk mengatur variabel menjadi pribadi tanpa menambahkan baris lain -atau memindahkannya ke baris baru- lebih dari tidak sering melihat kata kunci pribadi.

private var foo : String = "foobar" lebih sesuai dengan penggunaan kata kunci export dan onready juga.

Menutup mendukung https://github.com/godotengine/godot-proposals/issues/641 , karena proposal fitur sekarang dilacak di repositori proposal Godot.