Pengantar Visual Basic

Bahasa pemrograman Microsoft® Visual Basic® adalah bahasa pemrograman tingkat tinggi untuk Microsoft .NET Framework. Meskipun dirancang untuk menjadi bahasa yang mudah didekati dan mudah dipelajari, ini juga cukup kuat untuk memenuhi kebutuhan programmer berpengalaman. Bahasa pemrograman Visual Basic memiliki sintaksis yang mirip dengan bahasa Inggris, yang mempromosikan kejelasan dan keterbacaan kode Visual Basic. Jika memungkinkan, kata atau frasa yang bermakna digunakan alih-alih singkatan, akronim, atau karakter khusus. Sintaks asing atau tidak diperlukan umumnya diizinkan tetapi tidak diperlukan.

Bahasa pemrograman Visual Basic dapat berupa bahasa yang ditik dengan kuat atau dititik secara longgar. Pengetikan longgar menunda banyak beban pemeriksaan jenis sampai program sudah berjalan. Ini tidak hanya mencakup pemeriksaan jenis konversi tetapi juga panggilan metode, yang berarti bahwa pengikatan panggilan metode dapat ditangguhkan hingga run-time. Ini berguna ketika membangun prototipe atau program lain di mana kecepatan pengembangan lebih penting daripada kecepatan eksekusi. Bahasa pemrograman Visual Basic juga menyediakan semantik yang ditik dengan kuat yang melakukan semua pemeriksaan jenis pada waktu kompilasi dan melarang pengikatan run-time panggilan metode. Ini menjamin performa maksimum dan membantu memastikan bahwa konversi jenis sudah benar. Ini berguna saat membangun aplikasi produksi di mana kecepatan eksekusi dan kebenaran eksekusi penting.

Dokumen ini menjelaskan bahasa Visual Basic. Ini dimaksudkan untuk menjadi deskripsi bahasa lengkap daripada tutorial bahasa atau manual referensi pengguna.

Notasi Tata Bahasa

Spesifikasi ini menjelaskan dua tata bahasa: tata bahasa leksikal dan tata bahasa sintik. Tata bahasa leksikal menentukan bagaimana karakter dapat digabungkan untuk membentuk token; tata bahasa sintetis mendefinisikan bagaimana token dapat digabungkan untuk membentuk program Visual Basic. Ada juga beberapa tata bahasa sekunder yang digunakan untuk operasi pra-pemrosesan seperti kompilasi bersyarat.

Tata bahasa dalam spesifikasi ini ditulis dalam format ANTLR -- lihat http://www.antlr.org/.

Kasus tidak penting dalam program Visual Basic. Untuk kesederhanaan, semua terminal akan diberikan dalam casing standar, tetapi casing apa pun akan cocok dengannya. Terminal yang merupakan elemen yang dapat dicetak dari kumpulan karakter ASCII diwakili oleh karakter ASCII yang sesuai. Visual Basic juga tidak peka lebar saat mencocokkan terminal, memungkinkan karakter Unicode lebar penuh untuk mencocokkan ekuivalen Unicode lebar setengahnya, tetapi hanya berdasarkan token keseluruhan. Token tidak akan cocok jika berisi karakter campuran lebar setengah dan lebar penuh.

Jeda baris dan indentasi dapat ditambahkan untuk keterbacaan dan bukan bagian dari produksi.

Kompatibilitas

Fitur penting dari bahasa pemrograman adalah kompatibilitas antara versi bahasa yang berbeda. Jika versi bahasa yang lebih baru tidak menerima kode yang sama dengan versi bahasa sebelumnya, atau menafsirkannya secara berbeda dari versi sebelumnya, maka beban dapat ditempatkan pada programmer saat meningkatkan kodenya dari satu versi bahasa ke versi bahasa lainnya. Dengan demikian, kompatibilitas antar versi harus dipertahankan kecuali ketika manfaat bagi konsumen bahasa bersifat jelas dan luar biasa.

Kebijakan berikut mengatur perubahan pada bahasa Visual Basic antar versi. Istilah bahasa, ketika digunakan dalam konteks ini, hanya mengacu pada aspek sintaktik dan semantik dari bahasa Visual Basic itu sendiri dan tidak menyertakan kelas .NET Framework yang disertakan sebagai bagian Microsoft.VisualBasic dari namespace (dan sub-namespace). Semua kelas dalam .NET Framework dicakup oleh kebijakan penerapan versi dan kompatibilitas terpisah di luar cakupan dokumen ini.

Jenis pemutus kompatibilitas

Dalam dunia yang ideal, kompatibilitas akan menjadi 100% antara versi Visual Basic yang ada dan semua versi Visual Basic di masa mendatang. Namun, mungkin ada situasi di mana kebutuhan akan jeda kompatibilitas dapat melebihi biaya yang mungkin dikenakannya pada programmer. Situasi tersebut adalah:

• Peringatan baru. Memperkenalkan peringatan baru bukan, per detik, pemutusan kompatibilitas. Namun, karena banyak pengembang mengompilasi dengan "perlakukan peringatan sebagai kesalahan" diaktifkan, perawatan ekstra harus dilakukan saat memperkenalkan peringatan.

• Kata kunci baru. Memperkenalkan kata kunci baru mungkin diperlukan saat memperkenalkan fitur bahasa baru. Upaya yang wajar akan dilakukan untuk memilih kata kunci yang meminimalkan kemungkinan tabrakan dengan pengidentifikasi pengguna dan menggunakan kata kunci yang ada di mana itu masuk akal. Bantuan akan diberikan untuk meningkatkan proyek dari versi sebelumnya dan keluar dari kata kunci baru apa pun.

• Bug pengompilasi. Ketika perilaku kompilator berselisih dengan perilaku yang didokumenkan dalam spesifikasi bahasa, memperbaiki perilaku pengkompilasi agar sesuai dengan perilaku yang didokumenkan mungkin diperlukan.

• Bug spesifikasi. Ketika kompilator konsisten dengan spesifikasi bahasa tetapi spesifikasi bahasa jelas salah, mengubah spesifikasi bahasa dan perilaku kompilator mungkin diperlukan. Frasa "jelas salah" berarti bahwa perilaku yang didokumentasikan berjalan berlawanan dengan apa yang diharapkan sebagian besar pengguna yang jelas dan tidak ambigu dan menghasilkan perilaku yang sangat tidak diinginkan bagi pengguna.

• Ambiguitas spesifikasi. Ketika spesifikasi bahasa harus mengeja apa yang terjadi dalam situasi tertentu tetapi tidak, dan pengkompilasi menangani situasi dengan cara yang tidak konsisten atau jelas salah (menggunakan definisi yang sama dari titik sebelumnya), mengklarifikasi spesifikasi dan memperbaiki perilaku kompilator mungkin diperlukan. Dengan kata lain, ketika spesifikasi mencakup kasus a, b, d dan e, tetapi menghilangkan penyebutan apa pun yang terjadi jika c, dan kompilator berperilaku salah jika c, mungkin perlu untuk mendokumentasikan apa yang terjadi jika c dan mengubah perilaku kompilator agar cocok. (Perhatikan bahwa jika spesifikasinya ambigu tentang apa yang terjadi dalam situasi dan kompilator berulah dengan cara yang tidak jelas salah, perilaku pengompilasi menjadi spesifikasi de facto.)

• Membuat kesalahan run-time menjadi kesalahan waktu kompilasi. Dalam situasi di mana kode adalah 100% dijamin gagal pada runtime (yaitu kode pengguna memiliki bug yang tidak ambigu di dalamnya), mungkin diinginkan untuk menambahkan kesalahan waktu kompilasi yang menangkap situasi.

• Kelalaian spesifikasi. Ketika spesifikasi bahasa tidak secara khusus mengizinkan atau melarang situasi tertentu dan pengompilasi menangani situasi dengan cara yang tidak diinginkan (jika perilaku pengompilasi jelas salah, itu akan menjadi bug spesifikasi, bukan kelalaian spesifikasi), mungkin perlu untuk mengklarifikasi spesifikasi dan mengubah perilaku kompilator. Selain analisis dampak yang biasa, perubahan semacam ini lebih dibatasi untuk kasus di mana dampak perubahan dianggap sangat minimal dan manfaatnya bagi pengembang sangat tinggi.

• Fitur baru. Secara umum, memperkenalkan fitur baru tidak boleh mengubah bagian spesifikasi bahasa yang ada atau perilaku pengompilasi yang ada. Dalam situasi di mana memperkenalkan fitur baru memerlukan perubahan spesifikasi bahasa yang ada, pemutusan kompatibilitas seperti itu wajar hanya jika dampaknya akan sangat minimal dan manfaat fiturnya tinggi.

• Keamanan. Dalam situasi yang luar biasa, masalah keamanan dapat mengharuskan pemutusan kompatibilitas, seperti menghapus atau memodifikasi fitur yang secara inheren tidak aman dan menimbulkan risiko keamanan yang jelas bagi pengguna.

Situasi berikut ini bukan alasan yang dapat diterima untuk memperkenalkan pemutusan kompatibilitas:

• Perilaku yang tidak diinginkan atau disesalkan. Desain bahasa atau perilaku kompilator yang wajar tetapi dianggap tidak diinginkan atau disesalkan dalam retrospek bukanlah pembenaran untuk melanggar kompatibilitas mundur. Proses penghentian bahasa, yang tercakup di bawah ini, harus digunakan sebagai gantinya.

• Ada lagi. Jika tidak, perilaku kompilator tetap kompatibel mundur.

Kriteria Dampak

Saat mempertimbangkan apakah pemutusan kompatibilitas mungkin dapat diterima, beberapa kriteria digunakan untuk menentukan dampak perubahan. Semakin besar dampaknya, semakin tinggi bilah untuk menerima jeda kompatibilitas.

Kriterianya adalah:

• Apa cakupan perubahannya? Dengan kata lain, berapa banyak program yang mungkin terpengaruh? Berapa banyak pengguna yang kemungkinan akan terpengaruh? Seberapa umum menulis kode yang terpengaruh oleh perubahan?

• Apakah ada solusi untuk mendapatkan perilaku yang sama sebelum perubahan?

• Seberapa jelas perubahannya? Apakah pengguna akan mendapatkan umpan balik segera bahwa ada sesuatu yang telah berubah, atau apakah program mereka akan dijalankan secara berbeda?

• Dapatkah perubahan ditangani secara wajar selama peningkatan? Apakah mungkin untuk menulis alat yang dapat menemukan situasi di mana perubahan terjadi dengan akurasi sempurna dan mengubah kode untuk mengatasi perubahan?

• Apa umpan balik komunitas tentang perubahan tersebut?

Penghentian bahasa

Seiring waktu, bagian dari bahasa atau pengkompilasi mungkin menjadi tidak digunakan lagi. Seperti yang dibahas sebelumnya, tidak dapat diterima untuk memutuskan kompatibilitas untuk menghapus fitur yang tidak digunakan lagi tersebut. Sebagai gantinya, langkah-langkah berikut harus diikuti:

1. Mengingat fitur yang ada di versi A Visual Studio, umpan balik harus diminta dari komunitas pengguna tentang penghentian fitur dan pemberitahuan lengkap yang diberikan sebelum keputusan penghentian akhir dibuat. Proses penghentian dapat dibalik atau ditinggalkan kapan saja berdasarkan umpan balik komunitas pengguna.

2. versi lengkap (yaitu bukan rilis titik) B dari Visual Studio harus dirilis dengan peringatan kompilator yang memperingatkan penggunaan yang tidak digunakan lagi. Peringatan harus aktif secara default dan dapat dimatikan. Penghentian harus didokumenkan dengan jelas dalam dokumentasi produk dan di web.

3. Versi lengkap C Visual Studio harus dirilis dengan peringatan kompilator yang tidak dapat dinonaktifkan.

4. Versi lengkap D Visual Studio kemudian harus dirilis dengan peringatan kompilator yang tidak digunakan lagi yang dikonversi menjadi kesalahan kompilator. Rilis D harus terjadi setelah akhir Fase Dukungan Mainstream (5 tahun sejak penulisan ini) rilis A.

5. Terakhir, versi E Visual Studio mungkin dirilis yang menghapus kesalahan pengkompilasi.

Perubahan yang tidak dapat ditangani dalam kerangka kerja penghentian ini tidak akan diizinkan.