KAL
Menu

Semantik Package

Bagian api dan impl, penamaan package, serta maksud versioning yang direncanakan.

Daftar isi

Topik ini membahas semantik package Carbon, yaitu aturan pembagian program menjadi package sebagai satuan distribusi dan library sebagai satuan dependensi, lengkap dengan peran berkas api dan impl beserta penamaannya. Pembahasan ditutup dengan maksud versioning yang direncanakan proyek untuk bahasa dan toolchain. Setelah membacanya, struktur pengorganisasian program Carbon yang besar dapat dibedakan dari kebiasaan program satu berkas di Explorer, dan status implementasinya dapat dinilai secara jujur.

Package sebagai satuan distribusi#

Package adalah satuan distribusi dalam desain Carbon, dan setiap berkas sumber wajib menyatakan package-nya pada baris deklarasi pertama. Nama package berupa satu pengenal, misalnya Geometry, dan pengenal itu sekaligus menjadi ruang nama paling luar bagi seluruh isinya, sehingga tidak ada ruang nama global sama sekali dalam desain ini. Bentuk deklarasi dirangkum dokumen desain dengan pola (impl)? package IDENTIFIER (library STRING)?;, yaitu kata impl opsional untuk berkas implementasi, satu pengenal package, dan nama library opsional di dalam tanda kutip. Konvensi penamaan desain menetapkan gaya UpperCamelCase untuk nama package, sedangkan contoh yang berjalan di Explorer menggunakan huruf kecil seperti sample, dan keduanya masih berada pada tahap eksperimental.

Nama package pada dasarnya bebas dipilih, dan program satu berkas di Explorer memperlihatkan hal itu secara langsung. Program berikut menggunakan nama Konversi, dan eksekusinya berhasil tanpa aturan tambahan apa pun.

carbon paket-nama.carbon 
package Konversi api;

fn Main() -> i32 {
  Print("package Konversi berjalan");
  return 0;
}
text Keluaran 
package Konversi berjalan
result: 0

Kebebasan nama tersebut sejalan dengan tujuan desain, yaitu package dapat dikembangkan secara mandiri oleh tim yang berbeda tanpa saling mengetahui. Dokumen desain mengibaratkan satu package seperti satu repository GitHub, dengan proyek kecil dan menengah menggunakan satu package dan proyek besar memecah diri menjadi beberapa package. Pembagian semacam ini menempatkan penamaan sebagai keputusan penting, karena nama package menjadi awalan untuk seluruh nama publiknya, misalnya Geometry.Circle untuk tipe Circle di dalam package Geometry.

Library dan berkas api dan impl#

Library adalah satuan dependensi dalam desain Carbon, dan pembagian library merupakan dasar kerja sistem build, sedangkan package mengelompokkan library yang berkaitan. Setiap library terdiri atas tepat satu berkas api yang mendefinisikan antarmukanya dan nol atau lebih berkas impl yang mengisi implementasinya, dan keduanya dikenali dari kata impl pada deklarasi package atau library. Berkas impl mengikuti konvensi akhiran .impl.carbon, misalnya suhu.impl.carbon untuk berkas api bernama suhu.carbon. Nama pada berkas api bersifat publik secara bawaan dan dapat ditandai private, sedangkan nama yang hanya muncul di berkas impl otomatis privat dan hanya terlihat di dalam library yang sama.

Struktur api dan impl juga menentukan graf kompilasi. Dokumen desain menyatakan bahwa kompilasi umumnya bergerak dari berkas api yang saling bergantung, sedangkan berkas impl hanya bergantung pada berkas api, sehingga sistem build dapat mengurutkan pekerjaan dan memparalelkannya dari struktur itu sendiri. Import pun membedakan lingkup, yaitu import library "Shapes"; untuk library dalam package sendiri dan import Geometry library "Shapes"; untuk library milik package lain, yang hanya memperkenalkan nama Geometry sebagai awalan.

Rencana tersebut belum dapat diuji utuh di Explorer, karena Compiler Explorer mengeksekusi satu berkas sumber per program. Berkas impl berikut berdiri sendiri dan sah menurut desain, tetapi eksekusinya ditolak karena tidak memiliki titik masuk Main.

carbon paket-impl.carbon 
package Konversi impl;

fn KeFahrenheit(celsius: i32) -> i32 {
  return celsius * 9 / 5 + 32;
}
text Keluaran 
COMPILATION ERROR: <Main()>:0: could not resolve 'Main'

Versioning yang direncanakan#

Versioning Carbon direncanakan sebagai satu skema tunggal untuk bahasa, toolchain, dan standard library yang dirilis proyek utama. Skemanya mengikuti bentuk MAJOR.MINOR.PATCH yang bertumpu pada Semantic Versioning, dengan aturan bahwa perubahan yang tidak kompatibel ke belakang menaikkan MAJOR setelah pencapaian versi 1.0 dan menaikkan MINOR sebelumnya, sedangkan perbaikan bug menaikkan PATCH. Proyek bahkan mengatur bentuk pra-rilisnya secara rinci, yaitu rc.N untuk kandidat rilis, nightly dengan tanggal untuk build otomatis harian, dan dev untuk build pengembangan interaktif.

Alasannya dijelaskan secara terbuka dalam dokumen versioning. Pengalaman dengan C++ menunjukkan bahwa rilis yang benar-benar tanpa perubahan yang memutus kompatibilitas sangat sulit dicapai dan terlalu mengikat, sehingga Carbon memilih mengakui adanya perubahan semacam itu lalu menekan biayanya dengan alat pemutakhiran. Alasan lain bersifat teknis, karena Carbon menolak menjanjikan ABI yang stabil untuk seluruh bahasa dan library, sehingga kebebasan evolusi itu sengaja dipertahankan dan kompensasinya adalah alat pemutakhiran yang murah.

Versioning pada tingkat package belum ditetapkan dalam dokumen desain yang ada. Peta jalan proyek mencantumkan manajemen package sebagai pekerjaan jangka panjang pada rentang setelah 2028, bersama alat migrasi dan pengalaman pengembang ujung ke ujung, sehingga cara menyatakan versi sebuah package masih terbuka. Selama masa eksperimental ini, versi yang relevan bagi pembaca adalah versi trunk pada Compiler Explorer, dan skema MAJOR.MINOR.PATCH baru akan bekerja penuh ketika milestone 1.0 dicapai.

Ringkasan#

  • Package adalah satuan distribusi sekaligus ruang nama paling luar dengan satu pengenal nama, sedangkan library adalah satuan dependensi dengan tepat satu berkas api dan nol atau lebih berkas impl.
  • Deklarasi package menampung kata impl opsional dan nama library opsional, dan nama Main dicadangkan sehingga tidak dapat ditulis sebagai package.
  • Explorer mengeksekusi satu berkas dengan nama package bebas, tetapi menolak direktif library dan berkas impl tanpa Main, sehingga struktur penuhnya belum dapat diuji di sana.
  • Versioning direncanakan dengan satu skema MAJOR.MINOR.PATCH untuk bahasa dan toolchain, dan manajemen package tercatat sebagai pekerjaan setelah 2028.

Referensi#