Dalam waktu dekat, fitur-fitur baru akan muncul dalam bahasa Jawa, yang saat ini sedang dikerjakan di bawah proyek Valhalla, Panama dan Loom. Memperluas bahasa bukanlah tugas yang mudah, terutama bukan bahasa di mana penekanannya adalah pada kompatibilitas mundur; oleh karena itu, agar integrasi mereka ke Jawa berjalan lancar, arsitek bahasa harus menyelesaikan akumulasi masalah mendasar.
Kemarin (8 Januari), Brian Goetz, bekerja untuk Oracle sebagai Arsitek Bahasa Jawa, memposting
surat "Kami membutuhkan lebih banyak kata kunci, Kapten!" Ke milis Project Amber
. di mana ia mengusulkan cara untuk memecahkan masalah menambahkan kata kunci baru ke bahasa. Akibatnya, kata kunci dapat muncul dalam bahasa seperti
non-null ,
non-final ,
akhirnya-final dan
ini-kembali (daftar lengkap menunggu Anda di bawah cut-out di akhir posting).
Karena di masa lalu masalah ini jarang muncul dalam bahasa, mereka biasanya tidak terlalu memikirkannya dan “berusaha melepaskan diri secepat mungkin”; karena kekurangan dari pendekatan yang ada di masa depan, aplikasi mereka akan bermasalah, dan dalam hal ini, diputuskan untuk bekerja terlebih dahulu. Solusi yang diajukan: mencoba untuk memperluas set bentuk leksikal yang dapat digunakan sebagai kata kunci: izinkan kata kunci dipisahkan oleh tanda hubung, yang akan menggunakan satu (atau lebih) kata kunci yang ada atau pengidentifikasi yang dicadangkan.
Catatan Penting: Brown mencatat bahwa kata kunci baru disediakan semata-mata sebagai contoh ilustrasi, dan Anda tidak boleh fokus pada kata kunci tersebut. Namun, jelas bahwa kita memiliki di hadapan kita demonstrasi yang dipikirkan dengan matang tentang bagaimana sintaks bahasa dapat berubah di masa depan - dalam surat itu, penulis menyebutkan bahwa ide ini akan membantu untuk menambahkan banyak konstruksi bahasa yang tidak diinginkan yang diinginkan ke Jawa.
Metode "Lama"
Seperti yang Anda tahu, hari ini dalam bahasa Jawa ada 50 kata kunci (
kata kunci ), yang dilarang untuk digunakan sebagai pengidentifikasi variabel. Daftar lengkap diberikan
dalam spesifikasi bahasa JLS dalam klausa 3.9 . Daftar ini tidak banyak berubah sejak versi pertama bahasa - hanya pernyataan
yang ditambahkan dalam versi 4,
enum dalam 5 dan
_ dalam 9. Selain itu, ada juga "pengidentifikasi yang dicadangkan" -
true ,
false dan
null - yang berperilaku mirip dengan kata kunci cara.
Ketika pengembang perlu menambahkan kata kunci baru ke bahasa, mereka harus menggunakan salah satu metode berikut.
- Pemindahan kepemilikan secara paksa: kami mengambil kata-kata yang sebelumnya merupakan pengidentifikasi dan mengubahnya menjadi kata kunci (misalnya, menegaskan ).
- Pembuangan: kata kunci yang ada mulai digunakan dengan cara yang tidak pernah dimaksudkan untuk digunakan (contohnya adalah penggunaan default untuk nilai anotasi atau metode default).
- Lakukan tanpa itu: temukan cara untuk menggunakan sintaks yang tidak memerlukan kata kunci baru - misalnya, gunakan antarmuka untuk anotasi alih-alih anotasi - atau sepenuhnya meninggalkan fitur.
- Menciptakan visibilitas: buat ilusi kata kunci konteks-sensitif menggunakan pencapaian linguistik heroik ( kata kunci terbatas, nama tipe khusus ).
Pada prinsipnya, salah satu dari metode ini biasanya dapat diterapkan, tetapi masing-masing dari mereka memiliki kelemahan, dan untuk perluasan skala bahasa yang serius, metode ini saja jelas tidak cukup - untuk inovasi di masa depan, akan perlu untuk menghilangkan ketidakmampuan untuk memperluas sintaksis bahasa sepenuhnya.
Menambahkan Kata Kunci Baru
Ada argumen berikut yang menentang “hanya” mengambil dan menambahkan kata-kata baru.
- Semakin mudah dan populer kata kunci yang dipilih adalah, semakin sering ia menemukan kode sumber program, yang akan menambah ketidakcocokan ke bahasa (misalnya, ketika kata menegaskan muncul di Java SE 1.4, semua kerangka kerja pengujian berhenti bekerja).
- Biaya menghilangkan ketidakcocokan kode oleh pengembang akan sangat bervariasi dari kecil (mengubah nama variabel lokal) menjadi fatal (ketika metode antarmuka atau tipe publik tidak valid).
- Kata-kata yang kemungkinan besar digunakan oleh pengembang bahasa adalah pengidentifikasi populer (misalnya, nilai , var , atau metode );
- Jika Anda memilih kata-kata yang jarang digunakan dalam kode sumber dan dengan yang akan ada lebih sedikit tabrakan, Anda harus menggunakan konstruksi seperti biasanya_but_not_always_final , yang dalam bahasa itu secara alami diinginkan untuk dihindari.
- Namun, jika Anda memilih kata-kata yang jarang digunakan, maka menggunakan metode ini terlalu sering tidak akan berhasil - melanggar kompatibilitas tidak baik, dan tidak ada begitu banyak kombinasi yang lebih sukses.
Menggunakan kembali kata kunci "lama"
Tentang "hanya" terus hidup dengan kata-kata itu, ada pertimbangan.
- Preseden untuk penggunaan kembali kata kunci dalam konteks yang berbeda ditemukan dalam banyak bahasa pemrograman (contoh dari Jawa adalah penggunaan akhir ( (ab) ) untuk penunjukan "tidak bisa berubah", "tidak didefinisikan ulang" dan "tidak dapat diperpanjang").
- Terkadang pendekatan ini masuk akal dan datang dengan sendirinya, tetapi biasanya itu bukan prioritas.
- Seiring waktu, sekumpulan persyaratan untuk sekumpulan kata kunci meluas, dan itu bisa sampai pada titik lucu - tidak ada yang mau menggunakan nol final dalam kode mereka.
- Jika yang terakhir tampak berlebihan bagi Anda, maka perlu diingat bahwa ketika bekerja pada JEP 325 mereka serius menyarankan menggunakan saklar baru untuk menggambarkan saklar dengan semantik yang berbeda - jika Anda melanjutkan dengan nada yang sama, setelah sepuluh tahun kita dapat mencapai saklar baru baru .
Bagaimana cara hidup tanpa kata kunci baru? Dimungkinkan untuk sepenuhnya berhenti terlibat dalam evolusi bahasa, seperti yang disarankan beberapa orang. Tapi ini tidak serius dan tidak sesuai dengan pendapat yang lain, karena ada minat yang sehat pada fitur baru bahasa dari pengembang.
Kata Kunci Kontekstual
Kata kunci kontekstual yang digunakan untuk memberikan makna spesifik dalam kode, tetapi kata-kata yang tidak dicadangkan (
digunakan dalam C # ) pada pandangan pertama tampaknya sama dengan "tongkat ajaib", tetapi di sini Brian mengemukakan pandangannya sendiri tentang penggunaannya, berdasarkan praktik ( misalnya, implementasi
var di Java 10, yang bukan kata kunci, tetapi
nama tipe yang dicadangkan ). Sebagai imbalan atas ilusi menambahkan kata kunci baru tanpa harus “merusak” program yang ada, kami mendapatkan peningkatan kompleksitas dan distorsi dalam bahasa tersebut.
Kata kunci kontekstual sulit untuk penulis spec, kompiler, dan IDE. Dalam kasus ketika datang ke satu atau dua kasus khusus, ini tidak menyebabkan masalah, tetapi ketika mereka mulai digunakan di mana-mana, itu berarti biaya yang jauh lebih tinggi untuk mendukung kode atau ekor dari bug.
Orang bisa mengabaikan ini - kata mereka, ini bukan masalah pengguna bahasa, tetapi penciptanya dan mereka yang menulis kompiler dan IDE. Namun dalam kenyataannya, semua orang menderita. Untuk IDE, ini bisa menjadi masalah yang signifikan: diperlukan lebih banyak input untuk menebak apa yang dimasukkan pengembang - kata kunci atau pengidentifikasi kontekstual. Akibatnya, pengguna mendapatkan kemunduran dalam pekerjaan penyorotan sintaks, pelengkapan otomatis, dan kemampuan refactoring.
Anda dapat menggunakan alat ini, tetapi lakukan ini dengan hati-hati.
Distorsi lidah
Tampaknya dengan masalah-masalah yang disebabkan oleh pendekatan-pendekatan ini - sintaksis yang kikuk, komplikasi kehidupan dan bug yang tidak perlu - pada prinsipnya, kita dapat mengatasinya. Tapi ada masalah lain yang tidak terlalu jelas - nuansa menggunakan kata kunci mengarah pada kenyataan bahwa desain bahasa itu sendiri terdistorsi.
Untuk pengembang Java, menulis
antarmuka bukan
anotasi adalah hal yang lumrah saat ini, tetapi semua orang akan setuju bahwa menggunakan
anotasi istilah ramah alih-alih kombinasi @ dan kata kunci "lama" akan jauh lebih logis.
Contoh lain: set pengubah yang tersedia (publik, pribadi, statis, final, dll.) Tidak dapat disebut lengkap - kita tidak dapat mengatakan apa pun yang
tidak final atau
tidak statis . Pada gilirannya, ini berarti bahwa Anda tidak dapat membuat fitur di mana variabel atau kelas adalah
final secara default, atau anggota
statis secara default, karena tidak ada cara untuk menunjukkan bahwa kami ingin meninggalkan pengubah ini.
Masalah ini tidak begitu jelas bagi mereka yang menggunakan bahasa - tetapi penulis bahasa itu sendiri, karena keinginan mereka untuk mengembangkannya lebih lanjut, terus-menerus menjumpainya, dan kita semua harus membayar untuk keputusan seperti itu (ketika secara eksplisit, ketika secara implisit).
Kesimpulan dari semua hal di atas menunjukkan sendiri: kita membutuhkan sumber kata kunci lain.
Solusi yang diajukan
Dalam kemampuan eksperimental bahasa tersebut, sintaksis digunakan untuk pra-penunjukan kata kunci baru, di mana kata kunci baru sendiri didahului oleh dua garis bawah (misalnya, dalam prototipe
Project Valhalla itu
__ByValue ). Alasan untuk keputusan ini dapat dimengerti - Anda perlu menunjukkan bahwa ini adalah pengganti sementara, yang di masa depan Anda perlu membuat keputusan tentang sintaks akhir, dan pada saat yang sama Anda dapat dengan mudah menghindari konflik dengan kode yang ada. Orang dapat menyarankan menggunakan format yang sama untuk kata kunci baru - dimulai dengan satu atau dua garis bawah - tetapi solusi ini tidak dapat disebut cantik, karena dalam hal ini kita akan mendapatkan kebingungan dari kata kunci biasa dan baru.
Oleh karena itu, disarankan untuk menggunakan kata kunci yang dibuat menggunakan tanda hubung, yang akan menggunakan satu atau lebih kata kunci "lama" atau pengidentifikasi yang dicadangkan.
Tidak seperti
kata kunci yang dibatasi , pendekatan ini akan menciptakan lebih sedikit masalah untuk penguraian, karena (selanjutnya disebut sebagai contoh)
bukan-nol tidak dapat dikacaukan dengan ekspresi pengurangan, dan lexer selalu dapat menentukan apakah
ab adalah tiga token atau satu. Berkat ini, peluang baru terbuka bagi kami untuk membuat kata kunci yang jauh lebih kecil kemungkinannya bertentangan dengan kode sumber yang ada atau dengan satu sama lain. Selain itu, mereka lebih cenderung memiliki nama yang bermakna, karena banyak dari apa yang ingin ditambahkan oleh pembuat bahasa ke Jawa didasarkan pada konstruksi bahasa yang ada di dalamnya - misalnya,
bukan nol .
Sebagai contoh kata kunci baru, kemungkinan kandidat untuk tempat kata kunci baru diberikan (saya ingat bahwa menurut penulis, saat ini daftar ini murni ilustratif):
-
bukan nol ;
-
tidak final ;
-
Paket-pribadi (pengubah tingkat akses ke anggota kelas secara default, yang saat ini tidak ditunjukkan dengan cara apa pun);
-
baca publik (baca publik, direkam secara pribadi);
-
tidak dicentang ;
-
type-static (konsep yang diperlukan untuk
Valhalla ; menunjukkan statis dalam kaitannya dengan spesialisasi spesifik kelas, dan bukan kelas itu sendiri);
-
nilai default ;
-
akhirnya-final (apa yang sekarang seharusnya dilakukan menggunakan anotasi
Stable ),
-
semi final (sebagai alternatif untuk
disegel );
-
sakelar lengkap ;
-
enum-class ,
annotation-class ,
record-class (penulis bahasa dapat menggunakan kata kunci ini sebagai alternatif untuk
enum dan
antarmuka , jika mereka memiliki kesempatan seperti itu);
-
kelas ini (untuk menggambarkan kelas literal untuk kelas saat ini);
-
this-return (sering diminta untuk menambahkan cara untuk menandai setter / metode-builder sebagai mengembalikan penerimanya).
Tentunya ada varian lain dari skema leksikal yang menurutnya memungkinkan untuk menyusun kata kunci sehingga mereka secara minimal tumpang tindih dengan yang sudah ditulis oleh kode sumber. Tanda hubung yang diusulkan cukup mudah dibaca untuk mobil dan manusia.
Dapat dipahami bahwa pendekatan ini sama sekali tidak mengecualikan kemungkinan menggunakannya bersama dengan yang digunakan sebelumnya, tetapi akan digunakan bersama mereka.