Karena banyak orang menggunakan @Data dan @Value , tanpa secara eksplisit menggunakan @Getter , alangkah baiknya jika ada beberapa anotasi yang dapat menghasilkan efek yang sama untuk @Nullable bidang.

alih-alih membuat opsi seperti itu ke java hanya opsional, saya merekomendasikan versi yang lebih kuat, karena ada banyak implementasi seperti opsional (mis. Vavr - Option). Jadi saya sarankan untuk membuat fungsi yang dapat kita definisikan prosesor untuk pengambil, di lantai pertama itu adalah @Getter(processor=Optional.ofNullable), jadi nilainya pertama-tama dimasukkan ke metode Optional.ofNullable dan hasilnya dikembalikan oleh pengambil.

@baha2046 @Getter(processor=Optional::ofNullable) akan menjadi sintaks yang benar, tetapi Anda tidak dapat menggunakan referensi metode dalam anotasi dan tidak ada cara untuk menentukan metode, kecuali untuk metode yang diketik seperti @Getter(processor="Optional::ofNullable") , yang cukup buruk rupa. Sayangnya ini membuat versi yang lebih kuat menjadi kurang menarik.

Saya tidak berpikir Anda harus memiliki harapan untuk menambahkan ini ke lombok.

1214 dan daftar surat

kasihan.

=/

@rzwitserloot Saya menganggap sikap Anda tidak banyak berubah tentang masalah ini dan #1214.
Jika Anda mengikuti pengembangan jdk, jelas ada pandangan yang beragam tentang hal ini dan ada agenda latar belakang mengenai konversi Opsional ke tipe nilai yang tampaknya memengaruhi beberapa sikap tersebut - https://github.com/rzwitserloot/lombok/issues/ 1214#issuecomment -261511309.

Apakah ada jebakan teknis dengan menerapkan fitur ini atau hanya masalah agama/subyektif? Jika hanya yang terakhir, saya sangat ingin tim lombok naik di atasnya dan memiliki fleksibilitas untuk menambahkan fitur ini. Sebagai kompromi, tambahkan di bawah paket eksperimental dan dokumentasikan argumen di javadoc?

FWIW ada kerangka kerja lain yang memiliki dukungan untuk opsional (misalnya https://immutables.github.io/immutable.html#optional-attributes). Akan menyenangkan melihat dukungan ditambahkan ke Lombok yang IMHO memiliki penggunaan pengalaman dev yang lebih kaya dan lebih sederhana daripada alternatifnya.

meskipun saya setuju bahwa kadang - Optional dapat digunakan di bidang (saya secara khusus menyukainya untuk menulis pembuat yang membuat keputusan berdasarkan keberadaan apakah ada sesuatu yang diatur ), saya tidak selalu menginginkannya, jadi saya juga akan melakukannya seperti opsi untuk menghasilkan getter return Optional .

Menyetel ulang Optional untuk bidang yang dapat dibatalkan harus menjadi perilaku default IMO.

Skenario penggunaan yang paling umum adalah di JPA @Entity

Java.util.Optional tidak mengimplementasikan antarmuka Serializable. Untuk alasan ini, kita tidak boleh memetakan atribut entitas sebagai Opsional karena itu akan membatasi penggunaan entitas.

Solusinya adalah pindahkan Optional ke getter .

Seluruh dunia akan senang jika Lombok membantu dalam skenario ini...

Menyetel ulang Optional untuk bidang yang dapat dibatalkan harus menjadi perilaku default IMO.

Itu akan menjadi perubahan yang menyakitkan bagi banyak proyek. Paling tidak, perlu ada pengaturan lombok.config untuk itu, dan lebih baik memilihnya daripada memilih keluar.

Halo, ada berita tentang masalah ini? Saya juga ingin melihat fitur ini!

@rzwitserloot tidak menjawab komentar https://github.com/rzwitserloot/lombok/issues/1957#issuecomment -471434870 maka kita dapat berasumsi bahwa pendiriannya tentang topik ini tidak berubah - Opsional tidak akan mendapatkan perlakuan khusus dalam karyanya gudang

satu-satunya pilihan yang tersisa adalah melakukan garpu - ada yang tertarik?

Alih-alih forking, Anda juga dapat membuat handler baru yang membuat getter ini. Anotasi pengambil reguler tidak akan melakukan apa pun jika sudah ada pengambil.

Getter hanyalah contoh paling sederhana di mana dukungan untuk Optional diperlukan

permainan akhir adalah dukungan di Value dan Data

Saya pikir, akan sangat bagus untuk menggunakan kelas Java.util.Optional _by default_ , tetapi dapatkan dukungan untuk mengubahnya ke analognya. Yang paling saya maksud adalah kelas perpustakaan VAVR - dalam proyek saya, saya menggunakannya sebagai ganti java.util.Optional.

Saya pikir fitur ini akan bagus untuk ditambahkan. Setidaknya buatlah eksperimental sehingga masyarakat dapat melihat apakah itu solusi yang layak.

@Vyacheslav-Lapin @SDiamante13 baca seluruh utas sebelum memposting... Anda tidak mendapatkan fitur ini di sini

@walec51 Anda benar... pemilik repo memposting di sini bahwa lombok tidak akan menerapkan fitur ini, dan PR untuk ini tidak akan diterima. Dia tidak menjelaskan mengapa...

@walec51 Anda benar... pemilik repo memposting di sini bahwa lombok tidak akan menerapkan fitur ini, dan PR untuk ini tidak akan diterima. Dia tidak menjelaskan mengapa...

@gpr-indevelopment https://github.com/rzwitserloot/lombok/issues/2264 memiliki sedikit lebih banyak penjelasan. Sepertinya ini adalah preferensi untuk anotasi nullability. Saya lebih suka mendapatkan kesalahan waktu kompilasi ketika saya lupa menangani null tanpa menggunakan banyak alat lain, tetapi jelas ada pendapat yang kuat dari pemilik repo untuk mem-bypass sistem tipe. Jadi garpu atau tangani itu (pengambil manual). Inilah templat intellij untuk menghasilkan getter opsional jika itu membantu

#if($field.modifierStatic)
static ##
#end
Optional<$field.type> ##
#set($name = $StringUtil.capitalizeWithJavaBeanConvention(

    $StringUtil.sanitizeJavaIdentifier($helper.getPropertyName($field, $project))))
#if ($field.boolean && $field.primitive)
is##
#else
get##
#end
${name}() {
return Optional.ofNullable($field.name);
}

tetapi ada pendapat yang sangat kuat dari pemilik repo untuk mem-bypass sistem tipe.

Hati-hati. Itu sedikit menghina - tolong jangan salah mengartikan pendapat orang lain.

Kami berpendapat kuat bahwa itu adalah ide yang buruk untuk meledakkan perpustakaan yang ada selama 30 tahun dengan memperkenalkan perubahan mendasar yang tidak kompatibel ke sistem tipe.

Kami tidak memiliki pendapat yang kuat bahwa 'seseorang harus melewati sistem tipe'. Itu gila - menurut Anda apa yang ingin dicapai oleh @Value dan teman-teman?

jenis tag, jika dilakukan dengan baik, akan menjadi fantastis. Untuk Java, anotasi tampak seperti mekanisme yang jelas digunakan untuk menandai jenis. Sayangnya, tidak ada yang melakukannya dengan baik , kecuali beberapa kasus sudut yang tidak populer. Juga, fakta bahwa ada banyak perpustakaan yang bersaing di luar sana tidak membantu. Tapi, dari sudut pandang teknis, mereka hebat, dan lombok sudah mendukung banyak hal: Lombok mengenali banyak anotasi nullity dan berusaha keras untuk menghasilkan kode untuk mempertimbangkan hal ini. Itu tidak menghabiskan seluruh dokumen karena itulah intinya: anotasi dapat diintegrasikan tanpa membuang 30 tahun. Saya tidak PERLU menjelaskan bagaimana melakukannya, lombok kurang lebih secara diam-diam meningkatkan kode yang sudah dihasilkan dengan cara yang kompatibel ke belakang.

Yang membuat saya kembali ke:

tetapi ada pendapat yang sangat kuat dari pemilik repo untuk mem-bypass sistem tipe.

Ini salah. Dan saya tersinggung dengan karakterisasi ini.

tetapi ada pendapat yang sangat kuat dari pemilik repo untuk mem-bypass sistem tipe.

Hati-hati. Itu sedikit menghina - tolong jangan salah mengartikan pendapat orang lain.

Kami berpendapat kuat bahwa itu adalah ide yang buruk untuk meledakkan perpustakaan yang ada selama 30 tahun dengan memperkenalkan perubahan mendasar yang tidak kompatibel ke sistem tipe.

Kami tidak memiliki pendapat yang kuat bahwa 'seseorang harus melewati sistem tipe'. Itu gila - menurut Anda apa yang ingin dicapai oleh @Value dan teman-teman?

jenis tag, jika dilakukan dengan baik, akan menjadi fantastis. Untuk Java, anotasi tampak seperti mekanisme yang jelas digunakan untuk menandai jenis. Sayangnya, tidak ada yang melakukannya dengan baik , kecuali beberapa kasus sudut yang tidak populer. Juga, fakta bahwa ada banyak perpustakaan yang bersaing di luar sana tidak membantu. Tapi, dari sudut pandang teknis, mereka hebat, dan lombok sudah mendukung banyak hal: Lombok mengenali banyak anotasi nullity dan berusaha keras untuk menghasilkan kode untuk mempertimbangkan hal ini. Itu tidak menghabiskan seluruh dokumen karena itulah intinya: anotasi dapat diintegrasikan tanpa membuang 30 tahun. Saya tidak PERLU menjelaskan bagaimana melakukannya, lombok kurang lebih secara diam-diam meningkatkan kode yang sudah dihasilkan dengan cara yang kompatibel ke belakang.

Yang membuat saya kembali ke:

tetapi ada pendapat yang sangat kuat dari pemilik repo untuk mem-bypass sistem tipe.

Ini salah. Dan saya tersinggung dengan karakterisasi ini.

Nada saya terlalu agresif dan saya minta maaf untuk itu.

Namun, izinkan saya setidaknya menjelaskan mengapa saya tidak percaya itu salah karakterisasi. Menurut pendapat Anda, alasan Anda menemukan anotasi kurang adalah karena anotasi tersebut tidak dapat benar-benar membantu Anda memperbaiki masalah ini. Tentu mereka dapat menambahkan pemeriksaan runtime di mana-mana atau analisis statis untuk mencoba dan memperingatkan Anda tentang NPE, tetapi masalah sebenarnya adalah bahwa <strong i="19">@Nullable</strong> String dan <strong i="21">@NotNull</strong> String adalah tipe yang sama menurut sistem tipe Java dan tidak ada jumlah sihir anotasi akan mengubah fakta ini.

Yang mengarah ke

perubahan mendasar yang tidak kompatibel dengan sistem tipe

Saya gagal melihat bagaimana membuat kelas adalah perubahan yang tidak kompatibel dengan sistem tipe. Apakah menambahkan ArrayList di Java 1.2 merupakan perubahan mendasar yang tidak kompatibel dengan sistem tipe? Apakah setiap kelas yang dibuat pengguna merupakan perubahan pada sistem tipe? Jelas tidak (walaupun, dalam beberapa hal Anda dapat membantahnya karena Anda menciptakan tipe baru yang dapat dihuni, tetapi yang sebenarnya ingin saya katakan adalah bahwa tidak satu pun dari ini mengubah cara aturan sistem tipe Java diterapkan). Kami tidak memerlukan beberapa sintaks variabel nullable khusus untuk menyelesaikan masalah ini, dan saya akan sangat menentang menambahkan beberapa sintaksis gaya kotlin ? sama sekali tidak berguna (dan sangat spesifik untuk satu kasus penggunaan) gaya kotlin Maybe<T> != T dan kompiler Java tidak akan membiarkan Anda meneruskan/menggunakan Maybe<T> di tempat T diperlukan. Inilah artinya menggunakan sistem tipe dan tidak ada anotasi atau pemeriksaan runtime yang akan menyamai kemampuan ini. Mungkin Optional tidak dirancang untuk menjadi setara dengan tujuan umum Mungkin monad, tetapi tetap memenuhi persyaratan (dengan satu kasus tepi aneh untuk .map) karena yang Anda butuhkan hanyalah ofNullable dan flatMap .

Jika sebuah String adalah jenis jumlah kardinalitas tak terbatas dari null | "" | "a" ... , maka Optional<String> adalah jenis null | NONE | SOME("" | "a" | ...) .
Perbedaan penting adalah bahwa dalam kasus string murni, Anda cukup banyak harus menangani nol, tetapi dalam kasus mungkin, nol selalu merupakan kesalahan pemrograman yang tidak harus Anda tangani (arti semantik apa yang mungkin Anda miliki untuk menjaga terhadap opsional nol?). Jika Anda menjaga tepinya, sangat mungkin untuk tidak memiliki nol yang berarti dalam kode Anda yang sebenarnya. Ini memang mengharuskan Anda untuk membuat kode dengan asumsi bahwa tipe seperti String harus "" | "a" | ... tanpa null sebagai nilai, tetapi ini tidak sulit untuk dicapai/dianggap seperti yang Anda bayangkan.

Selain itu, saya bertanya-tanya mengapa orang-orang tampak sangat menentang penggunaan Optional sebagai parameter atau bidang ketika mereka sangat senang menggunakan List sebagai parameter dan bidang. Orang-orang akan "dengan senang hati" memanggil hal-hal seperti Collections.singletonList , tetapi jika Anda mengatakan call Optional.of ada perdebatan besar tentang hal itu. Ternyata koleksi 0 hingga N hal sangat, sangat berbeda dengan koleksi 0 hingga 1 hal.

Pernyataan terakhir itu cukup tepat di kepala.
Sejauh yang saya ketahui Optional<> hanyalah tipe lain dari kelas gaya Koleksi.

Itu sebabnya, alasan mengapa orang mengatakan itu sebagian besar karena perancang bahasa Brian Goetz mengatakannya.

Dan Brian mengatakannya karena dua alasan:

• dapatkan() penyalahgunaan. Dia menyebut metode itu "kesalahan API terbesar Java 8" karena orang yang terbiasa dengan koleksi akan mencoba menggunakan opsional seperti koleksi, mendapatkan overhead opsional tanpa manfaat apa pun.
• Serialisasi. Opsional tidak mengimplementasikannya, tidak seperti Koleksi.

(Dalam pandangan saya, Java seharusnya tidak lagi menggunakan Serializable. Setelah beberapa dekade buku memberi tahu orang-orang untuk tidak menggunakan serialisasi Java, antarmuka itu tidak lagi masuk akal.)

Dan ya, get() buruk. Yang itu juga bisa menggunakan penghentian.
Dan ya, ada penalti kinerja bukan nol. Tapi .. jika Anda ingin kinerja, apa yang Anda lakukan pemrograman di Jawa?

Menurut pendapat Anda, alasan Anda menemukan anotasi kurang adalah karena anotasi tersebut tidak dapat benar-benar membantu Anda memperbaiki masalah ini.

Tidak. Itu bukan alasan saya menemukan mereka kurang. Anotasi dapat sepenuhnya memperbaiki masalah ini.

Saya menemukan mereka kurang karena yang populer itu buruk. Secara khusus, itu adalah anotasi untuk metode dan bidang (dalam banyak hal, ini bukan kesalahan dari anotasi itu sendiri; anotasi pertama Java tidak memungkinkan mereka untuk menggunakan jenis apa pun, hanya pada metode/bidang/params), dan mereka tidak mempertimbangkan nulitas multivarian (lihat nanti untuk lebih lanjut tentang itu). Mereka juga tidak menggunakan kekuatan fleksibilitas, alias mereka juga tidak mempertimbangkan kebatalan warisan. Versi bagus dari perpustakaan semacam itu:

1. Didasarkan pada ElementType.TYPE_USE
2. Dikirim dengan sistem untuk menulis, dalam file teks atau beberapa bahasa non-java spesifik lainnya, daftar 'anotasi ini seharusnya telah diatur pada jenis ini dari perpustakaan yang umum digunakan, termasuk java.* itu sendiri.
3. Dikirim dengan plugin untuk IDE dan alat untuk menerapkan artinya, sejauh merasa sepenuhnya terintegrasi ke dalam IDE.
4. Ekosistem telah menyatu menjadi satu set anotasi.
5. Anotasi ini mampu menyampaikan semua 4 varians nullity (co-, contra-, in-, dan legacy).

Tidak ada yang cocok di luar sana. Dan hal-hal Opsional ini membuat penggabungan lebih sulit untuk terjadi, itulah sebabnya fanatisme Opsional mengganggu saya. Opsional adalah jalan buntu, jadi semakin cepat semua orang menyadari hal ini, semakin cepat kita bisa berhenti mengeluh tentang masalah NUI (saya tidak begitu yakin itu masalah besar), atau bergabung ke solusi yang layak.

Saya akan menjelaskan mengapa itu adalah jalan buntu, dan mengapa lombok tidak akan berkontribusi untuk mendorong masyarakat lebih jauh ke jalan buntu ini.

Tentu mereka dapat menambahkan pemeriksaan runtime di mana-mana atau analisis statis untuk mencoba dan memperingatkan Anda tentang NPE, tetapi masalah sebenarnya adalah bahwa @Nullable String dan @NotNull String adalah tipe yang sama menurut sistem tipe Java dan tidak ada sihir anotasi yang akan mengubah fakta ini .

Itu bukan 'masalah sebenarnya'. Tunjukkan pada saya bagaimana ini adalah 'masalah aktual', karena saya mengalami kesulitan melihat bagaimana ini entah bagaimana membuat tidak mungkin melakukan apa yang mungkin kita inginkan, yaitu memiliki alat, dokumen, bola mata manusia, dan IDE semuanya sesuai tentang kebutuhan untuk memeriksa nol atau kebutuhan untuk hanya melewati hal-hal yang pasti-bukan-null. Tentunya itulah inti dari latihan Optional, bukan?

Biarkan saya mencoba contoh spesifik ini: @Override tidak mengubah sistem tipe Java atau bahkan spesifikasi lang itu sendiri, namun tidak ada IDE, kompiler, atau alat linter di luar sana yang membingungkannya. Itu melakukan tugasnya, dan itu memperbaiki masalah. Dengan cara yang sepenuhnya kompatibel, tidak kurang. Anotasi nullity dapat melakukan hal yang sama, dan sudah melakukan hal yang sama: Jika Anda mengaktifkan pemeriksaan anotasi nullity misalnya Eclipse atau intellij, _and_ Anda bekerja dengan basis kode yang terisi penuh dengan info nullity dan tanpa skenario yang mengalami ( dipecahkan) masalah yang saya keluhkan sebelumnya, Anda _tidak akan pernah mendapatkan NPE yang mengejutkan lagi_. Masalahnya adalah, perpustakaan yang ada tidak memiliki info ini (tetapi perpustakaan yang ada juga tidak memiliki Opsional, jadi jangan buka tutup sampanye itu dulu), itulah sebabnya tidak ada yang melakukan ini. Selain itu, pustaka yang ada gagal untuk mempertimbangkan varians 4 arah penuh dan dengan demikian sistem akan rusak setelah Anda melibatkan sistem generik dan warisan. Tetapi itu adalah masalah yang secara teknis dapat diperbaiki, dan saya dapat menjelaskan kepada Anda dengan tepat bagaimana menuju ke sana. "API yang ada tidak menggunakan Opsional dalam jenis pengembaliannya" tidak dapat diperbaiki secara teknis, dan/atau Anda atau orang lain telah menjelaskan kepada saya bagaimana Anda memperbaikinya.

Saya gagal melihat bagaimana membuat kelas adalah perubahan yang tidak kompatibel dengan sistem tipe.

Itu karena kami jelas menggunakan definisi yang berbeda dari 'kompatibel mundur'. Maksud saya: "Memperkenalkan perubahan yang tidak kompatibel ke belakang pada bahasa berarti bahwa kode yang ada harus diubah dan/atau dikompilasi ulang, _atau dipaksa dianggap usang_". Yang terakhir kurang sering dinyatakan tetapi jelas benar. Lihat bagian berikutnya.

Apakah setiap kelas yang dibuat pengguna merupakan perubahan pada sistem tipe?

Saya tidak akan terlalu marah jika Anda membantu saya dengan menganggap saya bukan orang bodoh. Jelas bukan itu yang saya maksud, tolong jangan berdebat dengan itikad buruk.

Ambil java.util.Map dan metode get() . Jelas, jika Anda menemukan Optional ide yang bagus, metode ini harus jelas memiliki tanda tangan public Optional<V> get(Object key) . Ada 3 opsi yang bisa saya lihat:

1. Tidak ada yang salah dengan itu. Yang menyiratkan Opsional sebenarnya bukan ide yang bagus, atau saya kehilangan nuansa lain tentang Opsional. Saya ingin mendengar bagaimana Map.get tidak perlu Opsional dan tidak seharusnya, tetapi saya ragu itu adalah sudut pandang Anda.

2. Peta harus ditinggalkan/usang. Itu jelas sangat, sangat, _sangat_ tidak kompatibel.

3. Anda tidak melihat masalah khusus dengan ekosistem di mana beberapa API menggunakan null untuk menyampaikan tanpa nilai, dan API lainnya menggunakan Optional , dan tidak ada yang salah dengan ini. Tentunya saya tidak perlu menjelaskan bahwa ini _gila_, dan lebih buruk daripada dunia yang konsisten (bahkan dunia di mana nilai _NUI_ disampaikan dengan nilai null tidak terdokumentasi, hanya-runtime-only-checkable).

Jadi, pilihlah: Opsional tidak kompatibel ke belakang, atau tidak mungkin tanpa sihir voodoo, atau akan membagi komunitas menjadi dua. Opsi-opsi itu menyebalkan.

Jadi, kecuali Anda dapat menjelaskan beberapa opsi ke-4 kepada saya, atau menjelaskan bagaimana salah satu dari ini tidak menyebalkan: __Optional is bad__, untuk Java, seperti yang Anda inginkan: Tidak kompatibel dengan semua pengertian pragmatis dari kata itu.

Apakah menambahkan ArrayList di Java 1.2 merupakan perubahan mendasar yang tidak kompatibel dengan sistem tipe?

__Ya, tentu saja.__ Nah, 'dasar' bisa diperdebatkan. Faktanya, itu mungkin tidak mendasar, dan karena itu, dalam buku saya, perubahan yang menyakitkan tetapi dapat diterima. Itu juga sebagian akan kembali dan memperbaiki kesalahan, dan melakukannya hampir tepat waktu.

Swing sudah ada sebagai API pada masa itu, dan banyak metode swing menggunakan Vector dalam tanda tangan publik mereka. Kesalahan ini masih ada pada kita. Ini adalah javadoc dari DefaultTableModel swing dari j11 .

Ada Vektor di mana-mana. Sementara Oracle masih menyeret tumit mereka dan menemukan cara untuk secara resmi menyampaikan bahwa Vector sudah mati sebagai paku pintu (mereka menghemat @Deprecated untuk hal-hal yang pada dasarnya rusak atau tidak aman, seperti Thread.stop , bukan untuk hal-hal yang merupakan ide yang sangat buruk, tetapi berfungsi dengan baik). Tentunya kita semua bisa setuju bahwa Vector sudah usang, dan sama sekali tidak boleh digunakan hari ini - itu membuat kode Anda menonjol sebagai jempol yang sakit, itu punya API jelek yang gila (2 nama metode untuk sebagian besar hal, yang melakukan hal-hal yang identik), dan mereka tidak cocok dengan idiom Java umum (vektor selalu disinkronkan, bukan sesuatu yang biasanya Anda inginkan).

Untuk berjaga-jaga jika seseorang ingin berdebat itu tidak usang/usang: Ya, dan Oracle setuju: Istilah vektor sedang digunakan kembali dan direklamasi oleh Oracle untuk JSR338 . Penulis API itu ada dalam catatan (podcast "Jawa Masa Depan", sayangnya tidak ada transkrip untuk dicari) karena melakukan itu karena tidak ada yang menggunakan vektor lagi. Samar-samar saya ingat istilah 'usang' secara harfiah dikatakan.

__Namun ayunan masih memiliki crud__ ini. Itu membuatnya tidak kompatibel. Swing sekarang menjadi API yang jelek. Apa yang seharusnya dilakukan ayunan di sini?

1. Ubah Vektor ke Daftar. Ini adalah biner yang tidak kompatibel dalam hal apa pun, sumber kompatibel untuk semua penggunaan Vektor dalam parameter, tetapi sumber tidak kompatibel untuk bidang apa pun dan penggunaan dalam jenis pengembalian. Itu sudah lebih baik daripada yang bisa dilakukan Optional (yang merupakan sumber dan biner tidak kompatibel untuk semua penggunaan).
2. Menyerahlah, dan nyatakan swing sebagai perpustakaan akhir masa pakai yang usang, dan mulailah dari awal.
3. Lepaskan versi ayunan yang tidak kompatibel.
4. Tetap menggunakan API lama, memperumit masalah saat berinteraksi antar layanan (jika Anda ingin membuat DefaultTableModel, Anda harus mengambil Daftar Anda dan mengonversinya menjadi vektor terlebih dahulu), dan menggunakan API yang direkomendasikan secara paksa menghasilkan kode yang memiliki barang-barang usang di sana.

Semua opsi ini payah. Itu membuat pengenalan ArrayList 's transisi menyakitkan yang benar-benar merusak beberapa hal.

Ini tidak mendasar hanya karena Java 1.0 tidak dikirimkan dengan gagasan mendasar bahwa tipe koleksi adalah bagian intrinsik dari sistem tipe yang cocok untuk digunakan pada batas API. Itu datang dengan 1.1 yang membawa hierarki penuh (API koleksi).

dan saya akan sangat menentang menambahkan beberapa gaya kotlin yang sama sekali tidak berguna (dan sangat spesifik untuk satu kasus penggunaan)? sintaks ke java

Kami setuju. Solusinya adalah ketik tag. Kemampuan menulis-waktu untuk lebih spesifik tentang aspek sekunder dari jenis tertentu berguna. Sangat berguna untuk dapat menyampaikan, dalam tipe java, bahwa Anda menginginkan string 'html aman' - string yang telah diloloskan atau tidak bersumber dari input pengguna atau sumber tidak sah lainnya. Salah satu caranya adalah dengan memperkenalkan public class SafeHtmlString , tetapi masalahnya adalah varians, dan sudah saatnya saya menjelaskan ini.

Mari kita lakukan metode ini:

/**
 * Finds the first element in {<strong i="13">@code</strong> list} that matches {<strong i="14">@code</strong> predicate} and returns it.
 */
public static <T> T findFirst(List<T> list, Predicate<T> predicate) {}

Kode ini __tidak perlu spesifik__. Katakanlah saya punya:

List<Integer> listOfInts = new ArrayList<Integer>();
Predicate<Object> isInteger = x -> x instanceof Integer;

Saya __tidak dapat meneruskan ini ke findFirst __ karena varians pada obat generik itu salah. Dalam hal ini, metode findFirst __tidak peduli__ tentang kemampuan tertentu yang dimiliki daftar. Ini tidak 'memperluas' - findFirst tidak peduli dengan fitur penulisan daftar (karena implementasinya tidak pernah memanggil clear, set, add, addAll, retain, dll), hanya peduli tentang membaca, tetapi ada metode lain yang melakukannya . Dan karena findFirst tidak peduli, jika ia memberi tahu sistem tipe bahwa ia tidak peduli, sistem tipe bisa lebih lunak. Cara yang benar untuk melakukan ini sebenarnya:

public static <T> T findFirst(List<? extends T> list, Predicate<? super T> predicate) {}

Sejauh ini kita telah membahas 3 varians: Kovarian (param list ), Kontravarian (param predicate ), dan skenario rusak sebelumnya, di mana kami salah menerapkan invarian.

__Penanganan nol sama saja!__

Dan opsional tidak ada peluang. Hanya ada 2 hal dengan opsional: Ya, atau Tidak.

String x; // in Optional world, this cannot hold NUI
Optional<String> x; // potentially NUI: NoValue, Unknown, or Irrelevant

Itu 2 terlalu sedikit. Obat generik memiliki 4:

List<? extends Number>; // covariance
List<? super Number>; // contravariance
List<Number>; // invariance
List; // raw / legacy variance

dan ini membuka dan menutup pintu yang berbeda. nullity membutuhkan hal yang sama, dan opsional tidak dapat memberikan.

Menggunakan kelas may (dalam bentuk apa pun) pada dasarnya berfungsi karena a Maybe!= T

Dan itulah mengapa opsional sangat buruk.

Bayangkan metode ini:

/**
 * Finds the first element in {<strong i="23">@code</strong> list} which matches {<strong i="24">@code</strong> predicate}, and adds it to the end of {<strong i="25">@code</strong> list}, adding nothing if no element matches.
 */
public void duplicateFirstMatch(List<T> list, Predicate<T> predicate) {}

Metode ini menginginkan kovarians untuk nullity. Metode ini memiliki properti yang menyenangkan: Jika _BOTH_ daftar itu sendiri serta predikat mampu menangani NUI, maka pekerjaan metode tersebut dapat dilakukan. Jika keduanya tidak bisa, maka metode ini juga dapat melakukan - dan metode tersebut tidak akan pernah merusak tumpukan.

Katakanlah kita tinggal di tanah Jawa saat ini, dan NUI disampaikan dengan nilai nol dalam daftar saya. Saya sudah:

List<String> example = new ArrayList<>(List.of("hey", null, "world"));
Predicate<Object> isNull = x -> x == null;
duplicateFirstMatch(example, isNull);

Ini akan baik-baik saja, dan akan menghasilkan daftar saya mendapatkan elemen ke-4, dan itu nol, dan tidak apa-apa. Jika saya membubuhi keterangan status nulitas dari semua hal dalam contoh ini, itu sudah menjadi List<<strong i="5">@Nullable</strong> String> , dan jelas Predicate<<strong i="7">@Nullable</strong> String> . Menambahkan nol ke dalamnya tidak menjadi masalah. Tetapi, kode ini masih berfungsi jika saya memiliki List<<strong i="9">@NonNull</strong> String> : Metode duplicateFirstMatch tidak mungkin 'memecahkan' daftar dengan menambahkan null ke dalamnya, karena hanya dapat menduplikasi.

Ini hanyalah satu contoh spesifik tetapi kecil dari gagasan varians. Ini muncul _everywhere_ setelah Anda mulai berpikir tentang jenis penandaan.

Itu menunjukkan dengan jelas bahwa ide Anda untuk hanya menambahkan tipe eksplisit ( Optional<T> dalam hal NUI. Mungkin SafeHtmlString dalam hal string) tidak berfungsi. Keduanya mengarah ke inkompatibilitas mundur besar-besaran, dalam arti bahwa penggunaan jenis semacam itu secara luas hanya dapat terjadi jika sebagian besar perpustakaan yang ada sudah usang, dan itu mengarah ke bahasa yang tidak ekspresif, karena memaksa semua kode yang ditulis menjadi hitam-putih. , tanpa opsi penulisan kode yang beroperasi pada banyak hal dalam satu kelas tipe. Seperti duplicateFirstMatch yang merupakan kode yang berfungsi baik untuk kelas tipe nullity.

Untuk contoh lain yang sangat keren tentang apa yang dapat dilakukan penandaan huruf, pertimbangkan konsep 'Dipanggil' dari checkerframework . Anda dapat menulis metode ini:

public class PersonBuilder {
    // all sorts of 'setters', including birthDate(LocalDate bd) { .. }
    public Person build(@Called("birthDate") PersonBuilder this) { return new Person(...); }
}

Itu adalah typetag: Ini mengubah definisi penerima dari metode build (di atas adalah real, live, java yang valid, hari ini! Saya tahu bahwa this terlihat aneh, tapi itu java yang valid ). Itu mengubahnya untuk menyatakan: Penerima metode build() harus memiliki tag 'Sebuah instance dari PersonBuilder, tetapi, analisis kode memastikan bahwa birthDate dipanggil pada instance ini sebelumnya.

Ini sepenuhnya kompatibel ke belakang: Semua API yang ada dengan builder yang hanya mendokumentasikan 'tolong jangan panggil build() sebelum birthDate dipanggil pada builder, Anda akan merusaknya'. Hanya kode yang dengan sengaja melanggar aturan ini dan bergantung pada pengecualian yang keluar dari metode build() saat runtime yang akan menjadi kode yang [A] tidak bermasalah, dan [B] tetap rusak oleh perubahan ini. Itu jenis 'break of backward compatibility' yang baik-baik saja, karena pasti semua setuju bahwa penggunaan API pembangun hipotetis ini sebagian besar konyol, dan paling tidak begitu eksotis, tidak mungkin banyak mempengaruhi.

@rzwitserloot Terima kasih atas pembenaran terperinci. Keheningan relatif Anda sampai sekarang tentang apa yang menurut saya merupakan fitur yang paling Anda minta pernah mengecewakan.

Bagi saya, inti perdebatannya ada di sini: "Anda tidak melihat masalah khusus dengan ekosistem di mana beberapa API menggunakan null untuk menyampaikan tanpa nilai, dan API lainnya menggunakan Opsional, dan tidak ada yang salah dengan ini. Tentunya saya tidak perlu melakukannya. jelaskan bahwa ini gila"

Itu tidak terlihat gila bagi saya. Ekosistem utopis yang Anda impikan di mana anotasi datang untuk menyelamatkan kita tidak akan terjadi. Seperti yang Anda katakan, banyak yang telah mencoba dan banyak yang gagal. Kami telah memiliki anotasi selama bertahun-tahun. Jika itu belum terjadi, itu tidak akan terjadi.

Bagi saya, penggunaan Optional adalah bentuk peningkatan progresif. Saya tahu Peta mungkin mengembalikan nol, tetapi itu tidak menghentikan saya untuk menggunakan Opsional di semua API saya. Itu adopsi tidak berarti kita harus membuang bayi keluar dengan air mandi dan menulis ulang semuanya.

Apakah penggunaan Opsional berarti saya dapat sepenuhnya menutup mata dan tahu bahwa saya tidak akan pernah bisa mendapatkan NPE lagi? Tidak. Tentu saja saya harus berhati-hati dengan API yang lebih lama. Tapi itu sama di utopia Anda, di mana seseorang mungkin lupa menambahkan anotasi.

Beberapa inkonsistensi tidak bisa dihindari. Opsional adalah hal terdekat yang kita miliki dengan standar saat ini.

Akan sangat membantu jika seorang desainer bahasa Java membahas hal ini. Jika ada
adalah beberapa rencana keseluruhan yang diusulkan untuk memberi komunitas hashing arah
mengetahui detailnya hanyalah masalah mengubah perpustakaan sedikit demi sedikit,
cara yang sama dilakukan untuk obat generik dan anotasi.

Terlepas dari bentuk rencana ini, itu akan menyakitkan.

Saya pikir saya hanya ingin solusi yang memberi kita jalan ke depan, terlepas dari
bentuk, terutama.

Bagaimana hal yang kita tidak setuju, saya pikir.

Idealnya null tidak ada sebagai nilai. Varian yang dijelaskan Reinier
hanya ada karena null ada. Opsional tidak membahasnya karena itu
tidak dirancang untuk menghadapi situasi campuran-nullity - ini dirancang untuk
menyederhanakan hal-hal dengan menghapus nol dari persamaan sebagai gantinya.

Kompatibilitas mundur untuk Opsional akan terlihat seperti bertahap lambat
mengganti metode dan kelas yang tidak aman-nol, mencela hal-hal
selangkah demi selangkah. Menyakitkan, akan memakan waktu puluhan tahun, berarti kode lama rusak di beberapa
titik. Itulah hidup. Menghentikan kata kunci nol akan menjadi tujuan akhir. Bukan
mustahil, tapi sulit.

Jalur anotasi pada akhirnya tidak akan merusak kompilasi untuk kode lama.
Ini benar. Tetapi jika saya melihat kelas dengan ratusan peringatan karena itu
masih menggunakan instance Daftar mentah yang kodenya tidak kalah menyakitkan dan membutuhkan
memperbaiki dari kelas yang menggunakan nilai nol tanpa penjelasan apapun.

Jangan salah paham. Ketik tag batu. Tapi jalur tag tipe terlihat seperti orang mati
berakhir karena alasan sederhana bahwa belum ada gerakan tentang masalah ini
selama beberapa dekade. Satu-satunya jalan ke depan pada saat ini adalah upaya bersama untuk
bagian dari tim pengembangan Java untuk mengatasi hal ini.

Dan mereka harus. Java kehilangan keunggulannya di dunia pemrograman.
Google memindahkan Android ke Kotlin karena suatu alasan.
Java membuat langkah besar ke depan, saya hanya berharap itu cukup. Ini satu
alasan.

Pada Minggu, 6 Desember 2020, 11:19 Michael Boyles [email protected] menulis:

@rzwitserloot https://github.com/rzwitserloot Terima kasih atas
pembenaran rinci. Keheningan relatif Anda sampai sekarang tentang apa yang saya pikirkan
adalah fitur yang paling banyak diminta yang pernah mengecewakan.

Bagi saya, inti perdebatannya ada di sini: "Anda tidak melihat masalah khusus
dengan ekosistem di mana beberapa API menggunakan null untuk menyampaikan tanpa nilai, dan lainnya
API menggunakan Opsional, dan tidak ada yang salah dengan ini. Pasti aku tidak butuh
untuk menjelaskan bahwa ini gila"

Itu tidak terlihat gila bagi saya. Ekosistem utopis yang Anda impikan di mana
anotasi datang untuk menyelamatkan kami tidak akan terjadi. Seperti yang Anda katakan,
banyak yang mencoba dan banyak yang gagal. Kami telah memiliki anotasi selama bertahun-tahun. Jika
itu belum terjadi, itu tidak akan terjadi.

Bagi saya, penggunaan Optional adalah bentuk peningkatan progresif. aku tahu
Peta mungkin mengembalikan nol, tetapi itu tidak menghentikan saya untuk menggunakan Opsional secara keseluruhan
dari API saya. Itu adopsi tidak berarti kita harus membuang bayi itu bersama
air mandi dan menulis ulang semuanya.

Apakah penggunaan Opsional berarti saya benar-benar dapat menutup mata dan tahu saya bisa
tidak pernah mendapatkan NPE lagi? Tidak. Saya harus berhati-hati dengan API lama
kursus. Tapi itu sama dalam utopia Anda, di mana seseorang mungkin lupa untuk menambahkan
sebuah anotasi.

Beberapa inkonsistensi tidak bisa dihindari. Opsional adalah hal terdekat yang kita miliki
standar sekarang.

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/rzwitserloot/lombok/issues/1957#issuecomment-739482325 ,
atau berhenti berlangganan
https://github.com/notifications/unsubscribe-auth/AABIERIWSDTJEGWBOUGL52TSTNLEXANCNFSM4GGCNXZQ
.

@michaelboyles menulis:

Itu tidak terlihat gila bagi saya. Ekosistem utopis yang Anda impikan di mana anotasi datang untuk menyelamatkan kami tidak akan terjadi

Aku di pagar ini. Saya dapat melihat bagaimana posting saya sebelumnya terdengar seperti saya 100% setuju dengan masa depan nullity-via-anotasi, tetapi saya tidak: Saya pikir ini adalah yang terbaik dan sejauh ini, hanya strategi yang layak secara teknis untuk mencapai a skenario di mana java idiomatik memiliki penjaga yang dibawa tipe terhadap penggunaan _NUI_ yang salah. Itu saja - saya tidak mengatakan bahwa saya pikir masa depan ini akan terjadi. Saya hanya mengatakan: Itu bisa, dan itu akan lebih baik dari apa yang kita miliki. vs. opsional, yang tidak bisa, dan jika entah bagaimana saya salah dan itu benar-benar terjadi, akan lebih buruk daripada status quo saat ini. Kehadiran banyak perpustakaan nullity yang bersaing, mungkin didukung oleh rangkaian peristiwa yang tidak menguntungkan di mana JSR305 awalnya akan membawa ini, tidak memiliki perpustakaan yang mudah dimasukkan (yaitu maven G:A:V target), tetapi tidak pernah berhasil, mungkin karena mereka terlambat menyadari null adalah _little_ lebih rumit dari sekedar @NonNull dan @Nullable , telah mengakibatkan ledakan Kambrium ini.

Dan jin itu sulit untuk dimasukkan kembali ke dalam kotak.

Tapi, Anda telah melewatkan poin yang saya coba sampaikan, saya pikir. Diberikan:

• Katakanlah ada ojava: Java hipotetis di mana Optional<T> adalah idiomatik (semua perpustakaan dan tutorial utama menyebutkannya, semua IDE utama mendukungnya dan menganggap Anda menggunakannya).
• Katakanlah ada mjava: Java hipotetis di mana setengah dari semua kode dan perpustakaan menggunakan Optional<T> , dan setengahnya menggunakan null , dan ini tidak akan pernah berubah sepanjang masa penggunaan bahasa ini.
• Katakanlah ada njava: Java hipotetis di mana anotasi nullity adalah idiomatik, dan mampu menyampaikan varians juga.
• Akhirnya, ada Java: Java yang kita miliki sekarang. runtime only nullity dan semuanya, dengan segelintir library nullity yang tidak lengkap dan setengah didukung.

Berikut argumen saya:

• ojava tidak akan pernah terjadi dari tempat kita sekarang.
• mjava adalah __mengerikan__, lebih buruk dari Java.

Anda sepertinya mencoba membuat argumen bahwa njava juga tidak akan pernah terjadi. Saya harap Anda salah dalam hal itu. Mengingat bahwa Anda sudah dapat melakukan njava di sebagian besar IDE, jelas tidak ada batasan teknis, tetapi tentu saja ada banyak masalah komunitas (dan obsesi dengan Optional ini tidak membantu). __Tapi itu tidak masalah di sini__ - mjava mengerikan, dan ojava tidak mungkin, oleh karena itu Opsional buruk. Saya memberi Anda njava sebagai cabang zaitun: Jika Anda benar-benar ingin pindah ke Java masa depan yang memiliki type-checked _NUI_ , saya mencoba menunjukkan caranya. Jika jenis semangat gila yang dihabiskan untuk vavr, opsional, dll akan dihabiskan untuk sistem penandaan _NUI_ berbasis anotasi yang tepat, maka mungkin itu sepertinya tidak terlalu tidak mungkin.

__Tapi intinya, mjava lebih buruk dari java__ - dan itulah sebabnya lombok tidak akan mendukungnya. Lombok akan membuat masa depan-jawa yang lebih buruk terjadi.

Bagi saya, penggunaan Optional adalah bentuk peningkatan progresif.

Itu adalah pemutarbalikan cronenberg-ian dari arti 'peningkatan progresif'. Ini sepenuhnya tidak kompatibel, bukan java idiomatik, dan tidak akan pernah. Ini sangat jauh dari konsep peningkatan progresif seperti pinguin dan beruang kutub.

Apakah penggunaan Opsional berarti saya dapat sepenuhnya menutup mata dan tahu bahwa saya tidak akan pernah bisa mendapatkan NPE lagi? Tidak. Tentu saja saya harus berhati-hati dengan API yang lebih lama. Tapi itu sama di utopia Anda, di mana seseorang mungkin lupa menambahkan anotasi

Tidak ada yang membuat argumen ini di kedua arah, jadi saya tidak yakin bagaimana ini relevan.

Opsional adalah hal terdekat yang kita miliki dengan standar saat ini.

Dengan asumsi interpretasi yang masuk akal dari kata 'standar', ini tidak benar. Jika Anda mengalikan tanda tangan metode apa pun yang ada dengan seberapa sering ia dipanggil di seluruh dunia dari tahun ke tahun, jumlah tanda tangan yang menyampaikan _NUI_ info melalui Optional artinya jika dibandingkan dengan jumlah yang menyampaikannya dengan anotasi nol, atau sistem yang otomatis menambahkan info ini dengan menggunakan sumber eksternal yang mencantumkan anotasi yang hilang.

@randakar menulis:

Akan sangat membantu jika seorang desainer bahasa Java membahas hal ini.

Brian Goetz telah membahasnya, sumber apa yang lebih baik? Saya dapat menyalurkan Brian sejenak - jangan ragu untuk memeriksa ulang ini dengannya, tetapi saya 95% yakin sudut pandangnya saat ini tentang situasi ini adalah ini:

1. Dia akan berpikir bahwa Optional sama sekali tidak memiliki harapan untuk kompatibel ke belakang. Dia tidak akan mengatakannya, dia tidak suka mengatakan 'tidak pernah'. Tapi dia akan menunjukkan dia tidak melihat rute, setidaknya.
2. Dia akan mengatakan bahwa ini membuat opsional solusi yang buruk untuk masalah ini.
3. Dia akan mengatakan bahwa 'masalah' _NUI_ tidak terlalu besar sehingga bahasa tersebut akan segera mati jika tidak ditangani. Untuk konteksnya, dia berpendapat bahwa kurangnya penutupan _WAS_ cukup besar untuk menjamin kebakaran 5-alarm di beberapa titik, tetapi masalah _NUI_ tidak.
4. Oleh karena itu, mengingat sulit untuk melakukan yang benar, dan sangat kontroversial: Dia tidak ingin membahasnya sekarang. Analisis nilai uang yang sederhana: Ini adalah biaya yang sangat tinggi untuk menyelesaikannya, terlebih lagi karena komunitas akan lebih siap daripada upaya sebenarnya untuk menemukan desain yang baik, dan manfaatnya rendah, karena kemungkinan sebagian besar komunitas akhirnya akan membencinya, karena itu bukan yang mereka inginkan, atau mereka menembak utusan itu karena mereka pikir itu sederhana dan berpikir bahwa solusi sebenarnya yang dibuat Brian dan rekan adalah 'direkayasa berlebihan' dan membuatnya lebih rumit daripada itu perlu.
5. Jadi, tidak ada gunanya menghabiskan waktu untuk apa pun. Ikan yang lebih baik untuk digoreng: Akses ke instruksi lebar asli CPU (API vektor baru, bagian dari panama - pikirkan: "Hei, CPU itu memiliki reg floating point asli 80-bit, dan register lebar 512-bit tempat Anda dapat menjalankan ops di paralel, bagaimana cara membukanya dari java?") - Valhalla, dll. Ini jauh lebih tidak kontroversial (karena komunitas akan lebih menyukai fitur ini), dan dengan demikian lebih murah (kurang 'berkelahi' dengan komunitas) dan banyak lagi berharga (karena lebih banyak yang akan menyukainya, meningkatkan kemungkinan komunitas mengadopsinya).

Saya pikir saya hanya ingin solusi yang memberi kita jalan ke depan, terlepas dari
bentuk, terutama.

Nah, kecaman teknis saya yang panjang pada semua opsi yang tersedia akan memberi tahu Anda bahwa tidak ada solusi teknis yang tersedia (dan jika Anda menginginkannya, jangan tanya insinyur oracle - buatlah satu), atau, itu adalah penandaan huruf berbasis anotasi. Bagaimanapun, Opsional tidak, dan tidak akan pernah bisa, itu.

Idealnya null tidak ada sebagai nilai.

Apa 'null' yang Anda maksud, di sini? Nilai waktu proses? Konsep _NUI_?

Jika yang Anda maksud adalah konsep _NUI_, maka ini adalah pernyataan yang salah. Mencoba membuat NUI hilang itu sulit, dan beberapa rute yang dapat dipikirkan (misalnya, memaksa setiap jenis untuk mencantumkan nilai default yang digunakan secara agresif) terdengar lebih buruk, karena mengarah ke bug diam alih-alih yang jelas, yang pasti lebih buruk.

Jika maksud Anda 'null', nilai referensi - maka pernyataan ini menyesatkan. null adalah salah satu cara untuk menyelesaikan NUI, mengapa 'ideal' jika 'tidak ada'? Itu hanya bisa dikatakan jika ada solusi NUI lain yang lebih unggul. Tidak ada satu.

Jika Anda bermaksud 'null' sebagai gelombang tangan yang mencakup keseluruhan ekosistem Java saat ini, yaitu nilai referensi dan gagasan bahwa sistem tipe tidak memiliki informasi tentang nullity dan tidak akan pernah - oke, mungkin. Tapi ada satu miliar solusi. Opsional adalah salah satu dari banyak solusi, dan solusi yang sangat buruk pada saat itu.

Kompatibilitas mundur untuk Opsional akan terlihat seperti bertahap lambat
menggantikan

Bukan itu yang dimaksud dengan 'kompatibilitas mundur'.

Tetapi jalur tag jenis terlihat seperti jalan buntu karena alasan sederhana bahwa belum ada pergerakan pada masalah ini
selama beberapa dekade.

Katamu. Ini adalah ramalan yang terpenuhi dengan sendirinya. Menurut Anda mengapa saya bertarung dengan baik dan mencoba menjelaskan mengapa Opsional adalah rencana yang buruk? Saya dapat melihat bagaimana Java masa depan di mana NUI ditangani dengan lebih baik pada waktu penulisan adalah Java yang lebih baik. Saya ingin itu terjadi. Langkah pertama adalah membuat segelintir orang fanatik yang begitu peduli tentangnya, menjauh dari jalan buntu.

tag tipe tampak mati bagi Anda karena Anda sangat menyukai Opsional. Lihat sedikit lebih jauh dan Anda akan melihat bahwa _actual support_ ada di IDE, dan semakin baik. Perlahan, mungkin - karena Optional mengeluarkan banyak oksigen dari ruangan.

Dan mereka harus. Java kehilangan keunggulannya di dunia pemrograman.

Saya telah mendengar itu selama 20 tahun. Sejauh ini, sudah kotoran kuda setiap kali dikatakan. Ini kotoran kuda sekarang.

Saya akan mencoba mengubah pikiran Anda.

Java saat ini kehilangan sedikit relevansi karena python digunakan untuk berintegrasi dengan AI dan matematika berbasis kartu GFX. Ini aneh karena Java jauh lebih cepat dan python tidak memiliki dukungan untuk register FP 80-bit asli CPU dan sejenisnya seperti Java tidak memiliki dukungan untuk ini. Tapi, python JAUH membuatnya lebih mudah untuk berintegrasi dengan C-libraries yang disediakan oleh misalnya nvidia untuk kuda dan sejenisnya. Java memiliki mekanisme untuk berintegrasi dengan mereka tetapi mereka berat; sedikit yang tahu caranya, dan sedikit yang tahu, perlu menghabiskan banyak waktu untuk melakukan pekerjaan dengan baik. Mencoba untuk kemudian berguling dengan pukulan dan meningkatkan 'fasad java' Anda dalam menghadapi pembaruan ke perpustakaan yang mendasarinya sangat sulit dilakukan dengan benar, tetapi kuda dan rekan banyak berubah sepanjang waktu.

Opsional? Bahkan di peta pun tidak.

Google memilih kotlin karena suatu alasan? Tentu saja. Alasannya adalah: Google LLC v. Oracle America, Inc

Saya akan sangat menghargai jika kita bisa menjauh dari angan-angan dan kesalahan logika untuk sisa utas ini. Mudah-mudahan saya telah memberikan latar belakang yang cukup dengan posting panjang ini - mulai sekarang, saya ingin melihat beberapa analisis teknis mendalam tentang apa yang dapat dilakukan untuk membuat opsional layak, dan jika gagal, saya akan mencoba untuk mengakuinya. posting yang menyertakan kesalahan logika dengan menyebutkan kesalahan tersebut dan tidak membuang kata-kata lagi pada topik tersebut.

@rzwitserloot Faktanya adalah bahwa mjava adalah apa yang sudah kita miliki. Anda mungkin tidak menyukainya, tetapi ini akan tetap ada di sini dan di sini. Streams sangat memanfaatkannya. Bagian JDK di masa depan kemungkinan besar akan memanfaatkannya. Perpustakaan akan semakin memanfaatkannya juga. Lihatlah masalah ini, sejauh yang dapat saya katakan tentang fitur yang paling banyak diminta. Orang-orang semakin banyak menggunakan Opsional.

Tidak ada yang membuat argumen ini di kedua arah, jadi saya tidak yakin bagaimana ini relevan.

Ini adalah satu-satunya kesimpulan yang saya dapat mengapa Anda akan berpikir campuran nol dan Opsional buruk - karena keberadaan Opsional mungkin membingungkan atau menyesatkan bagi pengembang. Jika bukan itu, lalu mengapa begitu mengerikan?

Jika Anda mengalikan tanda tangan metode apa pun yang ada dengan seberapa sering itu dipanggil di seluruh planet dari tahun ke tahun

Ini sepertinya spekulasi bagi saya. Saya akan tertarik untuk mengetahui apakah ada statistik yang tersedia. Tetapi bagaimanapun juga, saya cukup yakin bahwa JDK akan terus menggunakannya - saya tidak memiliki indikasi bahwa mereka menganggapnya sebagai kesalahan seperti yang Anda lakukan - dan adopsi akan meningkat karena semakin banyak orang yang terpapar. Jangan lupa, itu masih relatif baru dalam konteks seluruh bahasa.

Itu adalah pemutarbalikan cronenberg-ian dari arti 'peningkatan progresif'. Ini sepenuhnya tidak kompatibel

Saya berpendapat definisi Anda tentang tidak kompatibel ke belakang adalah apa yang sebenarnya memutarbalikkan definisi umum. Tapi jangan berdebat tentang semantik. Intinya adalah Optional dapat melihat adopsi yang lebih luas tanpa mempengaruhi API yang ditulis sebelum tersedia. Dan, sekali lagi, saya khawatir ini akan terjadi, terlepas dari pendapat Anda tentang hal itu.

Saya setuju bahwa kita sudah memiliki mjava. Dan saya tidak berpikir itu dalam rencana Oracle untuk segera menghentikan Optional. Inilah yang kita miliki sekarang.

Faktanya adalah bahwa mjava adalah apa yang sudah kita miliki.

Tidak. Beri nama saya perpustakaan yang biasa digunakan yang menggunakan Opsional. itu sangat sedikit. Itu harus tetap seperti itu.

tapi di sini dan di sini untuk tinggal.

Seperti yang dikatakan editor wikipedia, [rujukan?].

Perpustakaan akan semakin memanfaatkannya juga.

[rujukan?]

Orang-orang semakin banyak menggunakan Opsional.

[rujukan?]

Ini sepertinya spekulasi bagi saya.

Itu keluhan _menarik_ tentang alasan saya setelah paragraf yang Anda tulis yang mendahului ini!

Ya, tentunya. Tapi setidaknya satu Anda bisa memalsukan, dan ukuran yang jelas. Tidak seperti 'Orang-orang menggunakannya'. Itu tidak berarti (ya, tentu saja, Anda dapat menemukan satu programmer java yang melakukannya. Anda dapat menggunakannya untuk membenarkan ide yang paling gila. Atau 'orang' dianggap sebagai 'jumlah yang signifikan', tetapi kemudian Anda tidak 'bahkan tidak peduli untuk menyoroti bagaimana orang akan mengukur ini, apalagi membuat kasus bahwa ini benar. Saya mungkin orang yang perlu diyakinkan, di sini. Anda melakukan pekerjaan yang sangat buruk dalam hal itu, apa dengan kesalahan ini dan samar-samar, pernyataan yang tidak dapat dipalsukan.

Jika bukan itu, lalu mengapa begitu mengerikan?

Memiliki lebih dari satu cara untuk melakukan sesuatu meningkatkan kurva belajar, menimbulkan perdebatan gaya, dan memperumit masalah untuk kode yang terperangkap di antara 2 cara berbeda untuk mencapai hal yang sama. Oleh karena itu, jika ada 2 cara dalam melakukan sesuatu, dan Anda berdua menjadi bahasa yang umum, Anda perlu menjelaskan mengapa baik untuk memiliki 2 cara; agaknya, ada area signifikan di mana satu cara lebih baik dari yang lain, _dan_ area signifikan di mana kebalikannya benar. Ini jelas tidak terjadi pada Tag jenis opsional vs. untuk mewakili _NUI_ info di API.

Saya akan tertarik untuk mengetahui apakah ada statistik yang tersedia.

Jika Anda berusaha dan menunjukkan kepada saya hal-hal yang dapat dipalsukan, misalnya dengan menulis perayap untuk proyek github, Anda dapat meyakinkan saya. Bagian mana dari utas ini yang membuatnya tampak seperti saya akan terpengaruh oleh sekelompok orang yang mengatakan 'tetapi, @rzwitserloot , _I_ pikir itu hebat, mengapa Anda tidak bisa melihatnya?'

Saya telah memberi Anda argumen yang rasional dan dapat dipalsukan mengapa Optional itu buruk.

Entah menghalangi mereka (dan bukan dengan mengatakan Anda tidak menyukai argumen ini - dengan logika aktual (dan bukan kesalahan), angka aktual, atau implementasi teknis alternatif dari berbagai hal), atau jangan repot-repot.

Saya telah meminta argumen rasional dan saya tidak melihatnya. Aku sudah selesai dengan itu untuk satu tahun lagi.

Jika Anda merasa memiliki pandangan baru tentang solusi teknis, atau alasan spesifik mengapa argumen teknis seperti yang dinyatakan sebelumnya tidak dapat dihindari, silakan beri komentar di utas ini.

Saya tidak berpikir saya berutang penjelasan kepada Anda, tetapi saya tetap memberikannya. Permintaan fitur berakhir di sini. Perdebatan lebih lanjut tentang manfaat, atau kekurangannya, perlu mencari tempat lain.

@rzwitserloot

Sebutkan saya perpustakaan yang biasa digunakan yang menggunakan Opsional

Aliran, HttpClient (Java 11).

Ekosistem Java sudah sangat mapan, jadi fakta bahwa tidak ada perpustakaan pihak ketiga utama yang menggunakannya tidak berarti banyak. Sebutkan beberapa perpustakaan yang umum digunakan yang bermunculan pasca-Java 8. Saya tidak bisa memikirkannya.

tapi di sini dan di sini untuk tinggal.

Inkubator untuk akses memori asing Java menggunakannya. Itu belum dipublikasikan. Jadi penulis JDK masih aktif menggunakannya. Lagi pula, sejak kapan Java menghapus sesuatu?

Orang-orang semakin banyak menggunakan Opsional.

Anda memiliki 150 orang yang cukup peduli untuk menemukan masalah ini dan mendukungnya. Sekali lagi, fitur Anda yang paling banyak diminta.

Tentu saja Anda bebas melakukan apa yang Anda inginkan, tetapi jika Anda pikir Anda telah membantu komunitas Java dengan mengabaikan hal ini, Anda tidak melakukannya.

Ada juga cara untuk menolak permintaan dengan sopan tanpa bersikap kasar. Saya mengerti itu bisa membuat frustrasi jika Anda merasa seperti Anda terus-menerus harus membenarkan posisi Anda, tetapi mungkin fakta bahwa Anda harus melakukan itu seharusnya menjadi indikasi seberapa jauh Anda minoritas.

Terima kasih atas perpustakaan Anda, tetapi omong kosong "perlu kutipan" ini hanya kekanak-kanakan, dan dipasangkan dengan sikap umum Anda, Anda telah kehilangan banyak rasa hormat dari saya. Anda mengatakan dalam komentar sebelumnya, "Saya tidak akan terlalu marah jika Anda mendukung saya dengan menganggap saya bukan orang bodoh" dan sejujurnya, saya pikir banyak orang yang Anda balas di utas ini dapat mengatakan hal yang sama kembali kepada Anda.

Sebutkan beberapa perpustakaan yang umum digunakan yang bermunculan pasca-Java 8. Saya tidak bisa memikirkannya.

Jadi, Opsional ditakdirkan. Agar kami jelas, tujuan Anda adalah meyakinkan saya untuk menambahkan fitur ini atau mengizinkan permintaan PR. Anda malah membuat kasus yang seharusnya tidak kami lakukan. Yah, aku, uh, terima kasih, kurasa.

Aliran, HttpClient (Java 11).

Opsional awalnya 'ditemukan' untuk aliran. Ini adalah satu-satunya tempat di mana Opsional kurang lebih baik dan Anda harus mengikutinya: Jika Anda (entah bagaimana) menulis terminator aliran nilai tunggal Anda sendiri, Opsional dijamin. Itu berakhir di sana.

Anda memiliki 150 orang yang cukup peduli untuk menemukan masalah ini dan mendukungnya.

Lombok memiliki sekitar satu juta pengguna, dan ini bukan pertama kalinya java (dan pemrograman pada umumnya) memiliki gerakan fanatik di mana orang-orang berteriak pembunuhan berdarah dan sangat termotivasi untuk mengeluh dan membujuk. Sejarah biasanya menunjukkan bahwa mereka menggonggong pohon yang salah. Maksud dari cerita ini adalah, 150 suara tidak berarti apa-apa. Inilah sebabnya saya menginginkan detail teknis dan argumen yang dapat dipalsukan. Seruan kepada massa tidak berhasil; kefanatikan telah merusak itu bagi kita semua. Ini bukan salahmu sedikit pun. Hanya aspek yang disayangkan dari perdebatan tentang fitur bahasa pemrograman yang harus kita hadapi.

tetapi jika Anda berpikir Anda melakukan kebaikan bagi komunitas Java dengan mengabaikan ini, Anda tidak melakukannya.

Aku tidak mengabaikannya. Saya secara aktif mencoba untuk membatalkan penggunaannya. Saya melakukan ini, karena saya pikir saya membantu komunitas Java.

Ada juga cara untuk menolak permintaan dengan sopan tanpa bersikap kasar.

Jadi, jam + yang saya habiskan untuk menuliskan masalah teknis yang tepat yang saya miliki dengan Opsional, hanya memberikan semua yang tertarik tempat ke depan, dianggap tidak sopan?

Ya, saya mendapatkan itu banyak. Itu mungkin masalah budaya. Saya merasa frustrasi dan kasar jika saya menghabiskan waktu untuk permintaan fitur yang tampaknya serius, dan seseorang melemparkan senyum lebar berseri-seri ke arah saya dan berkata: OMG! Wah terima kasih banyak atas tanggapan Anda !!!! Kami akan menerimanya di bawah nasihat!! dan saya tidak pernah mendengarnya lagi.

Saya harap saya menyoroti bahwa saya telah menghabiskan cukup banyak waktu untuk masalah ini cukup bagi Anda untuk menyadari bahwa saya setidaknya menganggap ini serius. Sebaliknya (budaya, tidak diragukan lagi), tetapi saya menemukan penggunaan kesalahan logika yang terus-menerus dan menarik emosi dalam menghadapi penjelasan teknis yang dapat dipalsukan yang panjang tidak sopan, karena itu pasti terasa seperti sudut pandang saya diperlakukan seperti keset.

Bagaimanapun, dari sudut pandang saya, ini adalah kebalikannya: Saya melakukan kebaikan untuk pergi ke rumput liar dengan tepat mengapa saya cenderung mengajukan permintaan tentang Opsional ke bawah untuk memberi Anda jalan, hampir tidak mungkin seperti yang terlihat, seperti untuk bagaimana membuat opsional terjadi di lombok.

Anda telah kehilangan rasa hormat yang signifikan dari saya.

@rspilker biasanya menyarankan saya untuk menutup saja hal ini tanpa komentar, dan saya selalu sedikit kesal karena itu terasa tidak sopan.

Namun di sinilah kita. Sangat frustasi bahwa ini adalah di mana kita berakhir.

Terima kasih atas perpustakaan Anda, tetapi omong kosong "perlu kutipan" ini hanya kekanak-kanakan

Saya telah berulang kali menyoroti bahwa saya menginginkan beberapa hal yang dapat dipalsukan, dan saya belum mendapatkan barang-barang yang tidak dapat dipalsukan. Mengingat bahwa saya menghabiskan lebih banyak kata di utas ini kepada orang lain sejauh ini, Anda telah salah mengartikan maksud saya. Ini bukan kekanak-kanakan. Saya menyadari bahwa saya telah melampaui anggaran waktu saya untuk masalah ini dengan margin yang cukup besar dan berusaha menjadi lebih efisien untuk menebus kerugian.

Komentar terakhir Anda ini, setidaknya, mencoba memberi saya beberapa hal yang dapat dipalsukan dan detail teknis yang sebenarnya - jika percakapan lebih mengarah ke arah ini, mungkin akan berakhir di tempat lain.

Seperti, anggaran tahunan untuk diskusi tentang null/opsional sebagian besar dihabiskan, saya sangat meragukan lombok sebagai manfaat proyek jika kita menghabiskan lebih banyak waktu untuk ini.

150 suara tidak berarti apa-apa

Ya 150 dari 1 juta bukan apa-apa. Tetapi tidak setiap pengguna memiliki akun GitHub, atau cukup peduli untuk mencari permintaan fitur, atau akan meningkatkannya. "Mayoritas diam". Tapi Anda masih 150 lawan 2, sejauh yang saya tahu. Seperti yang saya katakan, fitur Anda yang paling banyak diminta; jika itu tidak penting bagi Anda, atau indikasi konsensus komunitas maka baiklah, tetapi saya tidak dapat melihat siapa pun yang setuju dengan Anda. Masuk akal bahwa kita semua 150 bodoh, tentu saja, dan itu tampaknya menjadi premis dari mana Anda bekerja.

orang-orang berteriak pembunuhan berdarah

Pak, tidak ada yang berteriak, kecuali mungkin Anda. Saya merasa semua orang di utas ini telah menghormati dan mencoba berdebat dengan itikad baik. Anda meninggalkan penjelasan yang panjang dan dengan demikian membiarkan diri Anda terbuka untuk sanggahan. Saya telah lama menerima bahwa permintaan ini tidak terjadi, dan telah mengatakan berkali-kali bahwa tidak ada yang mencoba memaksa Anda untuk melakukan apa pun, tetapi saya melihat ini sebagai kesempatan untuk menemukan pemahaman bersama. Sayangnya, Anda tampaknya tidak memiliki keinginan untuk memberi orang rasa hormat karena berpikir mereka mungkin tahu atau melihat sesuatu yang tidak Anda ketahui.

Aku melakukan kebaikan untukmu

Ya, dan saya berterima kasih untuk itu. Perilaku Anda setelah titik itu buruk.

Saya akan meninggalkan Anda dengan itu. Saya dapat memberitahu Anda bahwa Anda frustrasi dengan masalah ini, tetapi frustrasi bukanlah pola pikir yang baik untuk mendekati percakapan yang saling menghormati.

Terima kasih atas penjelasannya, sangat mencerahkan pikiran Anda.
Saya sangat menghargai dunia x-java yang telah Anda buat.

Saya kira kita pada dasarnya tidak setuju pada kemampuan ojava untuk muncul. Spring, hibernate, jackson, adalah perpustakaan yang cukup besar dengan dukungan opsional dan cukup kuat dalam mode mjava, yang dapat saya sebutkan di atas kepala saya. Mengingat bahwa sebagian besar perpustakaan terus mendukung versi Java <8, mungkin perlu waktu lama untuk transisi penuh terjadi, tetapi saya berharap apis secara bertahap berubah di dunia perpustakaan pihak ketiga hanya secara intrinsik berbasis opsional atau bahkan menyediakan kedua apis ( seperti yang dilakukan banyak dari mereka saat ini untuk memungkinkan dukungan beberapa versi). Banyak yang sudah membagi 8+ karena lambdas. Dengan pencocokan pola (dan mungkin tipe nilai) untuk Java 17, saya hanya berharap lebih banyak perpustakaan pihak ketiga bergerak ke arah ini.

Dukungan base sdk sebenarnya adalah titik sakitnya. Mengenai map.get , Anda benar, saya rasa tidak ada jawaban yang luar biasa, tetapi saya sebenarnya baik-baik saja dengan kegilaan mjava seperti yang Anda katakan, jika itu berarti saya sebagian besar bekerja di ojava dan Saya hanya perlu menyelesaikan beberapa panggilan SDK.

Jika maksud Anda 'null', nilai referensi - maka pernyataan ini menyesatkan. null adalah salah satu cara untuk menyelesaikan NUI, mengapa 'ideal' jika 'tidak ada'? Itu hanya bisa dikatakan jika ada solusi NUI lain yang lebih unggul. Tidak ada satu.

Alasan saya mendorong ini adalah karena saya percaya ojava lebih unggul. Dalam praktiknya, Anda dapat memiliki bahasa tanpa nilai nol, karena kami memiliki hal-hal seperti haskell dan ocaml yang ada untuk digunakan sebagai referensi. Saya jelas bias, tetapi saya ingin Java lebih dekat dengan ini, terlepas dari seberapa layak tujuan akhir 100%. Saya sebenarnya tidak memiliki masalah dengan mereka membuat metode antarmuka Peta baru untuk Optional<V> get(Object key) .

Bahkan jika njava muncul dan didukung dengan sempurna, saya masih akan menggunakan opsional, karena ini bukan hanya tentang mengetahui apakah suatu nilai bisa nol atau tidak, ini juga tentang menanganinya dengan cara yang sangat standar dan umum.
Sebagai contoh, saya benci kode go mengingat ini idiomatis

v1, err := f1()
if err != nil {
    return
}
v2, err := f2(v1)
if err != nil {
    return
}
v3, err := f3(v1, v2)
if err ...
... 

Menulis implementasi flatMap secara manual untuk setiap baris kode bukanlah sesuatu yang ingin saya lakukan. Saya tidak akan pernah mengerti mengapa orang berpikir ini adalah kode yang bagus/sederhana dan bukan kekacauan yang dipenuhi kebisingan yang gagal menyampaikan apa yang sebenarnya ingin Anda lakukan (saya pikir orang-orang masuk ke pemrograman untuk menghindari tugas yang berulang). Demikian pula, saya ingin menghubungkan metode opsional dengan flatMap, sesuatu yang menggunakan anotasi tidak membantu meringankan. Mungkin saya bukan orang yang tepat untuk bertanya karena saya juga menggunakan perpustakaan pihak ketiga untuk menambahkan kelas Try dan Anda akan melihat tanda tangan seperti
Try<Optional<String>, Exception> method(String a) (walaupun saya yakin Anda dapat mengetahui beberapa input dan output legal dan beberapa makna melalui tanda tangan ini saja). Manfaatnya adalah saya tidak memerlukan ide/anotasi/rantai alat/ekosistem khusus untuk membuat ini berfungsi; Saya hanya perlu javac dan sistem tipe yang ada.

Untuk salah satu contoh

Dan opsional tidak ada peluang. Hanya ada 2 hal dengan opsional: Ya, atau Tidak.

string x; // di dunia Opsional, ini tidak dapat menampung NUI
Opsionalx; // berpotensi NUI: NoValue, Unknown, or Irrelevant

Itu 2 terlalu sedikit. Obat generik memiliki 4:

Daftar memanjang Nomor>; // kovarians
Daftar Nomor super>; // kontravarian
Daftar; // invarian
Daftar; // varian mentah / lama

Ini bukan contoh yang bagus karena orang akan memilih contoh yang sebenarnya mengingat ini legal

Optional<? extends Number>; // covariance
Optional<? super Number>; // contravariance
Optional<Number>; // invariance
Optional; // raw / legacy variance

dan bahkan tampaknya tidak menjadi maksud Anda sama sekali. Saya masih sangat bingung pilihan lain apa yang ada untuk nilai yang diberikan di atas ya, memiliki nilai atau tidak, tidak memiliki nilai. Apakah ada status ketiga untuk pemeriksaan nol normal yang saya lewatkan? Jika Anda menggunakan opsional, mengapa Anda mewakili data apa pun dengan nol? Apa yang coba ditunjukkan oleh contoh ini?

Tanpa harus masuk ke setiap poin, saya kira alasan saya bahkan mengomentari masalah ini, adalah karena dalam kode saya sendiri, saya mencoba bekerja di ojava. Saya tidak memerlukan metode yang terkadang menangani nol atau mengizinkan nol, atau menangani daftar dengan nilai nol sebagai elemen daftar yang valid. Saya membuat asumsi bahwa tipe String tidak memiliki null sebagai nilai legal dalam kode saya sendiri. Sebenarnya, diskusi ini, lebih dari yang lain, membuat saya menyadari betapa sewenang-wenangnya tidak menggunakan Optional sebagai peringatan bidang/parameter sebenarnya, jadi saya pikir saya akan baik-baik saja hanya dengan @Value . Orang-orang di scala dan seluruh host bahasa fungsional berhasil mengetahuinya dengan baik tanpa sintaks khusus.

Saya memahami masalah kompatibilitas mundur yang Anda kemukakan, tetapi saya rasa perasaan pribadi saya adalah bahwa kemajuan memaksa pengorbanan. Saya tidak berharap kode Java lama rusak (sebagian besar waktu [penghapusan javax di 11 menonjol]), tetapi saya tidak akan mempertimbangkan terjebak dengan api lama sebagai status quo yang hebat juga jika diketahui menyebabkannya banyak kesalahan. Seperti contoh ayunan, bukan salah mereka bahwa mereka harus bekerja dengan alat yang diberikan kepada mereka, tetapi kadang-kadang Anda hanya harus membuat pilihan yang akan merugikan untuk kebaikan yang lebih besar (apakah ada yang benar-benar berpikir default untuk disinkronkan adalah ide yang bagus?) . Koleksi, obat generik, lambda adalah semua contoh yang, baik atau buruk, benar-benar usang dengan kode lama "baik". Rekaman dan pencocokan pola mungkin akan melakukannya lagi.

@ayush-finix

Seluruh posting Anda adalah angan-angan dan tidak memiliki pernyataan yang dapat dipalsukan atau alasan logis. Ini banyak 'Saya percaya' dan 'Saya ingin' dan 'Saya pikir'. Istilah 'perasaan pribadi' muncul beberapa kali. Ini bukan tempat.

Apakah ada status ketiga untuk pemeriksaan nol normal yang saya lewatkan?

Ya. Daftar dapat mengizinkan string, atau tidak. Jadi mengapa ada 3 cara untuk menulis List<String> ( String , ? extends String , ? super String )? Jika itu tidak membantu Anda memahaminya, baca ulang metode contoh saya yang menduplikasi elemen pertama yang cocok dengan predikat dan tulis untuk saya. sepenuhnya. di ojava. Anda tidak akan bisa.

@ayush-finix

Seluruh posting Anda adalah angan-angan dan tidak memiliki pernyataan yang dapat dipalsukan atau alasan logis. Ini banyak 'Saya percaya' dan 'Saya ingin' dan 'Saya pikir'. Istilah 'perasaan pribadi' muncul beberapa kali. Ini bukan tempat.

Saya mengerti bahwa ada banyak pemikiran pribadi di dalamnya, tetapi itu untuk menjelaskan sudut pandang saya, bukan untuk menjadi kebenaran objektif.
Tetapi untuk meledakkan semuanya karena tidak ada pernyataan yang dapat dipalsukan atau alasan logis?
Saya sedang melihat perpustakaan Java populer dan bahasa pemrograman lain yang menangani nilai NUI.
Sial, sesuatu seperti scala memiliki Option dan null juga karena interop Java.

Apakah Anda benar-benar ingin saya membahas lebih dalam tentang dukungan perpustakaan yang tepat?
Saya tidak berpikir itu relevan untuk menunjukkan hal-hal seperti spring-data Optional<T> findOne method dan modul jdk8 jackson yang mendukung opsional.
Jelas perpustakaan berubah dari 0 dukungan (pra opsional) ke beberapa dukungan (posting opsional). Apakah pertumbuhan akan berlanjut adalah pertanyaan terbuka.
Namun, secara obyektif benar bahwa ada perpustakaan java populer di m-mode untuk masa mendatang.

Apakah Anda ingin saya memberikan lebih banyak contoh dari bahasa lain yang tidak memiliki nol atau yang memiliki nol dan mungkin mengetik bersama?

Apakah kekhawatiran Anda tentang konsep tipe Opsional atau hanya implementasi Opsional ke dalam java?
Saya pikir Anda baru saja menunjukkan kesulitan implementasi mengubah api untuk menggunakan Opsional, yang merupakan bagian pertama dari komentar tentang bagaimana perpustakaan pihak ketiga sudah bergerak ke arah itu, tetapi sekarang sepertinya Anda tidak setuju dengan Opsional mengetik sebagai konsep.
Jika kita memulai bahasanya dari awal, apakah menurut Anda ojava masuk akal, secara teoritis?

Menggunakan kelas mungkin (dalam bentuk apa pun) pada dasarnya berfungsi karena a Maybe != T

Dan itulah mengapa opsional sangat buruk.

Tapi itulah intinya. Begitulah cara Anda mendapatkan kompiler yang sebenarnya untuk memastikan kebenaran tanpa toolchain bekerja atau memalsukan tipe dependen dengan anotasi atau menambahkan sesuatu seperti kerangka checker ke semuanya.
Saya sekarang mengerti maksud Anda tentang konsekuensi kompatibilitas ke belakang, tetapi Anda juga dapat memikirkan sisi positifnya memiliki metode kenyamanan yang bagus untuk menangani konsep NUI dengan mudah (flatMap/map to chain, orElse to unpack) dan kompiler Java biasa membantu programmer dengan mereka niat yang dinyatakan.

Ini tampaknya menjadi titik pertikaian kami. Anda tampaknya merasa bahwa mengubah api yang ada untuk menggunakan opsional adalah beban besar yang dapat dihindari dengan menambahkan lebih banyak dukungan rantai alat, sementara saya jelas merasa bahwa campuran api di jalur ke semua opsional dapat diterima. Sementara saya pikir kita dapat dengan hormat tidak setuju (dan pada akhirnya lombok adalah milik Anda), mengutip posisi Anda sebagai objektif dan logis sementara secara harfiah ada bahasa (scala) yang telah menempuh jalur kedua atau bahasa baru yang ada di kedua sisi kasus (go vs rust sebagai contoh) paling tidak jujur.

Apakah ada status ketiga untuk pemeriksaan nol normal yang saya lewatkan?

Ya. Daftar dapat mengizinkan string, atau tidak. Jadi mengapa ada 3 cara untuk menulis List<String> ( String , ? extends String , ? super String )?

Subtyping, yang tampak seperti masalah ortogonal dari nullability atau apa artinya tipe.

Jika itu tidak membantu Anda memahaminya, baca ulang metode contoh saya yang menduplikasi elemen pertama yang cocok dengan predikat dan tulis untuk saya. sepenuhnya. di ojava. Anda tidak akan bisa.

Mengabaikan poin bahwa (di dunia saya) tidak akan ada nilai nol dalam daftar sehingga implementasi saya dan versi Anda akan terlihat hampir identik, jika Anda ingin melakukan terjemahan yang paling mekanis:

public <T> List<T> duplicateFirstMatch(List<T> list, Predicate<T> predicate) {}

ke

public <T> List<Optional<T>> duplicateFirstMatch(List<Optional<T>> list, Predicate<Optional<? super T>> predicate) {
  return Stream.concat(
      list.stream(),
      list.stream().filter(predicate).findFirst().stream()
  ).collect(Collectors.toList());
}

tampaknya bekerja dengan baik?
Memang, ini

Predicate<Optional<Object>> pred = x -> !x.isPresent()
duplicateFirstMatch(list, pred)

tidak akan berhasil dari atas kepalaku, tetapi mengapa kamu tidak mengikat

Predicate<Optional<? super String>> pred = x -> !x.isPresent();
duplicateFirstMatch(list, pred);

omong-omong. Saya yakin orang lain dengan pengetahuan umum yang lebih baik bahkan dapat membuat Predicate<Optional<Object>> berfungsi karena seharusnya cukup mirip dengan List<List<T>> , tapi mungkin saya salah di sini.
Beberapa komentar:
Tidak ada niat untuk melindungi dari daftar nol atau predikat nol, karena ini hanya kesalahan programmer langsung di oworld.
Predikat mengambil Optional super T> memaksa seseorang menulis predikat untuk "menangani" kasus NUI karena parameter lambda yang diterima adalah Opsional. Mereka tidak perlu memeriksa nol ini karena ini juga merupakan kesalahan programmer di oworld.

tapi itu untuk menjelaskan povku

Ini bukan tempat.

Apakah Anda benar-benar ingin saya membahas lebih dalam tentang dukungan perpustakaan yang tepat?

2022, mungkin. Seperti halnya, anggaran waktu untuk ini telah dihabiskan untuk sesi 2021 tentang debat nulitas. Tapi, ya, itu akan lebih baik daripada daftar keyakinan Anda yang panjang dan tidak dapat dipalsukan.

berikan lebih banyak contoh dari bahasa lain

Tentu saja tidak. Bahasa lain sama sekali tidak ada hubungannya dengan masalah ini; itu hampir tidak relevan untuk debat desain bahasa untuk java itu sendiri, dan hampir sepenuhnya tidak relevan untuk lombok secara khusus. Bicara tentang jawa.

tapi sekarang sepertinya Anda tidak setuju dengan tipe Optional sebagai sebuah konsep.

Ini tidak benar. Saya selalu tidak setuju dengan tipe Optional sebagai sebuah konsep. Saya telah menyatakan keduanya:

• Opsional secara umum bukanlah solusi yang bagus untuk NUI, untuk bahasa apa pun.
• Khusus untuk java, Optional jauh lebih buruk, karena tidak memiliki cara untuk memperbaiki API yang ada, dan java (ekosistem) memiliki banyak API yang ada dan tradisi lama untuk tidak meninggalkan API yang ada (rujukan?, tetapi, beban pembuktian bukan pada saya!)

Subtyping, yang tampak seperti masalah ortogonal dari nullability atau apa artinya tipe.

Kemudian Anda masih tidak mengerti. Baca terus.

public <T> List<Optional<T>> duplicateFirstMatch(List<Optional<T>> list, Predicate<Optional<? super T>> predicate) {

Ini rusak. Di sini, itu tidak berfungsi:

List<String> list = ...;
// duplicate first long string
duplicateFirstMatch(list, str -> str.length() > 10);

Sebelum Anda menindaklanjuti dengan:
public <T> List<T> duplicateFirstMatch(List<T> list, Predicate<? super T> predicate) {

Yang itu juga tidak berfungsi, karena yang itu akan gagal di sini:

List<Optional<T>> list = ...;
// duplicate first present entry
duplicateFirstMatch(list, optStr -> str.isPresent());

Saya ingin satu metode yang akan bekerja untuk keduanya. Berikut adalah sistem berbasis anotasi hipotetis yang memberikan, dan berfungsi, hari ini, saat ini, di java. Dari checkerframework:

public <<strong i="36">@PolyNull</strong> T> List<T> duplicateFirstMatch(List<T> list, Predicate<? super T> predicate) {
    for (T t : list) if (predicate.test(t)) {
        list.add(t);
        return;
    }
}

Saya dapat memanggil ini dengan List<<strong i="39">@Nullable</strong> String> dan itu akan:

• Bekerja (kompilasi, jalankan, dan lakukan apa yang Anda pikirkan)
• Periksa (seperti, jika kode dFM saya berjalan, katakanlah, t.toLowerCase() , itu akan menyebabkan kesalahan waktu kompilasi yang menjelaskan bahwa saya mempertaruhkan pengecualian nullpointer di sini.
• Baca (seperti dalam, PolyNull didokumentasikan, dan perkakas dan dokumen dapat mengetahui hanya dari tanda tangan bahwa kode ini berfungsi dengan varian nolitas, tetapi predikatnya juga harus dapat menanganinya dengan tepat).

Saya juga dapat memanggil ini dengan `List< @NonNull String>:

• Ia bekerja sama (mengkompilasi, menjalankan, dan melakukan apa yang Anda pikirkan). Khususnya, panggilan .add(t) tidak akan menyebabkan kesalahan 'berpotensi menambahkan null ke daftar non-nulls', karena proses kompilasi menyadari bahwa t tidak boleh nol.
• Periksa (seperti, jika kode dFM saya berjalan, katakanlah, list.add(null) , itu akan mengeluh).
• Membaca.

Dokumentasi tentang @PolyNull

Tunjukkan pada saya bagaimana melakukan ini dengan Opsional.

Maaf jika aku merasa seperti membuang-buang waktumu. Saya mengerti bahwa masalah ini tidak akan berubah, jadi jika Anda tidak ingin menanggapi, saya tetap ingin mengucapkan terima kasih atas waktu yang telah Anda luangkan. Pada titik ini, ini lebih merupakan latihan pembelajaran daripada hal lain.

Ini tidak benar. Saya selalu tidak setuju dengan tipe Optional sebagai sebuah konsep. Saya telah menyatakan keduanya:

* Optional in general is not a great solution to NUI, for any language.

* For java in particular, Optional is much worse, in that it has no way to retrofit existing APIs, and java (the ecosystem) has a ton of existing API and a long-standing tradition to not abandon existing API (citation needed, but, the burden of proof isn't on me!)

Saya memahami pemikiran Anda tentang poin 2, dan saya tidak setuju dengan penilaian Anda terhadap ruang lingkup perubahan.

Poin 1 tampak seperti pernyataan yang sangat berani untuk dibuat yang benar-benar membutuhkan pembenaran dari pihak Anda. Mengapa tipe yang mungkin buruk untuk haskell atau karat? Pernyataan ini tampaknya tidak masuk akal.

Tentu saja tidak. Bahasa lain sama sekali tidak ada hubungannya dengan masalah ini; itu hampir tidak relevan untuk debat desain bahasa untuk java itu sendiri, dan hampir sepenuhnya tidak relevan untuk lombok secara khusus. Bicara tentang jawa.

Bagaimana kita membahas Opsional dalam ruang hampa? Untuk Java, kami memerlukan perubahan api tanpa dukungan rantai alat khusus.

Kemudian Anda masih tidak mengerti. Baca terus.

public <T> List<Optional<T>> duplicateFirstMatch(List<Optional<T>> list, Predicate<Optional<? super T>> predicate) {

Ini rusak. Di sini, itu tidak berfungsi:

List<String> list = ...;
// duplicate first long string
duplicateFirstMatch(list, str -> str.length() > 10);

Sebelum Anda menindaklanjuti dengan:
public <T> List<T> duplicateFirstMatch(List<T> list, Predicate<? super T> predicate) {

Yang itu juga tidak berfungsi, karena yang itu akan gagal di sini:

List<Optional<T>> list = ...;
// duplicate first present entry
duplicateFirstMatch(list, optStr -> str.isPresent());

Gagal dalam arti apa?

public static <T> List<T> duplicateFirstMatch(List<T> list, Predicate<? super T> predicate) {
    return Stream.concat(
        list.stream(),
        list.stream().filter(predicate).findFirst().stream()
    ).collect(Collectors.toList());
  }

dengan

public static void main(String[] args) {
    List<String> example = List.of("1", "2", "12345678901");
    System.out.println(example);
    example = MyClass.duplicateFirstMatch(example, s -> s.length() > 10);
    System.out.println(example);

    List<Optional<String>> example2 = List.of(Optional.of("1"), Optional.of("2"), Optional.of("12345678901"));
    System.out.println(example2);
    example2 = MyClass.duplicateFirstMatch(example2, o -> o.map(s -> s.length() > 10).orElse(false));
    System.out.println(example2);
}

memberi

[1, 2, 12345678901]
[1, 2, 12345678901, 12345678901]
[Optional[1], Optional[2], Optional[12345678901]]
[Optional[1], Optional[2], Optional[12345678901], Optional[12345678901]]

Apa yang saya lewatkan? Jika Anda menggunakan Opsional maka memiliki List<String> atau List<Optional<String>> dengan nilai nol adalah kesalahan yang tidak perlu Anda waspadai karena tidak ada kasus semantik yang berarti apa yang Anda inginkan .
Jadi jika saya melihat List<String> , saya dapat menganggap tidak ada nilai nol, dan jika saya melihat List<Optional<String>> , saya dapat menganggap tidak ada nilai nol, dan jika saya melihat List<?> Saya dapat berasumsi bahwa daftar tersebut tidak pernah berisi nilai nol, dan lebih jauh lagi bahwa List itu sendiri tidak pernah nol. Inilah artinya bekerja di dunia ojava penuh: tidak ada nilai nol yang diizinkan.
Saya tidak memerlukan beberapa versi metode duplikatFirstMatch (satu untuk @Nullable vs satu untuk @NotNull ), saya hanya memerlukan satu metode duplikatFirstMatch dengan tanda tangan yang persis seperti yang Anda daftarkan karena kami telah menghapusnya @Nullable dari ruang lingkup yang harus kita perhatikan.

benar-benar membutuhkan pembenaran di pihak Anda

saya sudah menyediakannya. Dalam detail yang agak ekstrim. Perbedaan itu, sebagai permulaan. Masih ada lagi, tetapi ini bukan tempat untuk penghancuran penuh pada sistem NUI.

Pernyataan ini tampaknya tidak masuk akal.

[rujukan?]. Penalaran logis, argumen yang dapat dipalsukan, atau tidak peduli. Ini bukan keduanya.

Bagaimana kita membahas Opsional dalam ruang hampa?

Kekosongan? Apa yang kamu bicarakan? Konsep NUI dapat dinyatakan dalam sejumlah perpustakaan di luar sana. Sesuatu yang sederhana seperti "bagaimana seharusnya sebuah bahasa menangani gagasan bahwa panggilan seperti map.get() perlu menyampaikan 'ups, nilai itu tidak ada di peta ini sejak awal' adalah tempat yang bagus untuk memulai diskusi.

Jangan ragu untuk membawa pilihan bahasa lain, tetapi hanya jika Anda menggunakannya untuk berbagi detail teknis tentang masalah apa yang mereka hadapi, contoh penggunaan, tetapi dengan pemahaman bahwa Anda kehilangan sebagian dalam terjemahan (idiom berbeda, budaya berbeda). Yang Anda lakukan hanyalah mengatakan 'Opsional itu hebat - bahasa ini menggunakannya dan mereka hebat'. Sebagian besar pernyataan itu tidak logis, juga tidak dapat dipalsukan. Satu-satunya bagian yang dapat dipalsukan adalah 'bahasa-bahasa ini menggunakannya'. Tentu. Tapi itu tidak membuat seluruh kalimat menjadi logis, atau bisa dipalsukan, jadi, itu bukan argumen dan tidak memiliki kekuatan meyakinkan.

Gagal dalam arti apa?

Itu tidak dikompilasi. List<String> tidak kompatibel dengan List<Optional<String>> . Cobalah. Tulis, jalankan javac di atasnya, tunjukkan kepada saya bahwa ini berfungsi dengan baik. Anda tidak bisa, karena tidak.

public static <T> List<T> duplicateFirstMatch(List<T> list, Predicate<? super T> predicate) {

Itu bukan kode yang Anda tulis sebelumnya. Itu juga gagal - tetapi di telepon. Saya tidak dapat menambahkan string yang diketik 'non-NUI' ke daftar ini. Kontras dengan misalnya List<? extends Number> yang memungkinkan Anda memberikan List<Number> atau List<Integer> . Dua jenis yang berbeda; jenis yang biasanya sama sekali tidak kompatibel satu sama lain (Mengingat List<Number> x = ..; List<Integer> y = ..; , baik x = y; maupun y = x; mengkompilasi. Namun, saya dapat menulis metode di mana Anda dapat melewatkan x , atau y . Satu metode. Dua jenis yang tidak kompatibel. Namun demikian, berfungsi dengan baik.

Saya ingin satu metode. Dua jenis yang tidak kompatibel ( List<String> dan List<Optional<String>> , atau, untuk membawanya ke titik sebenarnya, List<However you would like to convey the notion of String that cannot have no-value> dan List<However you would like to convey String-or-no-value> ) - tetapi dengan semacam tanda pada metode itu, bahwa kompiler memberi saya dua hal:

• Anda dapat melewati kedua jenis yang tidak kompatibel ini.
• Aturan pengetikan yang berlaku untuk metode itu diperluas untuk memastikan keamanan. Seperti dalam, tidak peduli apa metodenya, itu harus bekerja dan tidak merusak invarian terlepas dari berbagai jenis yang kompatibel yang benar-benar dilewatkan. Dalam kasus List<? extends Number> , kompiler tidak akan membiarkan Anda menulis list.add(someNumber); . Itu untuk memastikan Anda tidak menambahkan dobel ke List<Integer> secara tidak sengaja. Saya ingin keamanan ini juga.

Saya tidak akan membicarakan contoh ini lebih jauh, kita berada di kedalaman 10 lapisan dan pada titik ini, entah saya payah dalam menjelaskannya, Anda payah dalam memahami hal ini, atau Anda tidak dalam pola pikir yang benar untuk mempertimbangkan masalah dengan fitur bahasa yang Anda pilih untuk menjadi juara. Lebih banyak kata tidak akan memperbaiki semua itu.

Oke, demi menghormati keinginan Anda, saya tidak akan menindaklanjutinya.

Masih ada lagi, tetapi ini bukan tempat untuk penghancuran penuh pada sistem NUI.

Di mana saya bisa melihat pembongkaran penuh yang Anda rujuk untuk pemahaman saya sendiri?
Saya masih agak bingung tentang bagaimana Maybe tidak berfungsi di Haskell karena tidak memiliki subtipe (jadi masalah varians secara harfiah bukan masalah) dan benar-benar menyediakan fungsi pengangkatan. Sejujurnya saya tidak yakin apa alternatif dalam bahasa itu, tetapi mari kita abaikan itu dan berbicara tentang Java.

Sunting: Temukan tempat di mana ide-ide terdaftar: https://github.com/rzwitserloot/lombok/wiki/COMPLEXITIES :-Nullity-in-the-type-system

Dan saya pikir saya menemukan poin utama ketidaksepakatan kami:

@NonNull String adalah subtipe dari @Nullable String

Seperti yang telah Anda tunjukkan, menggunakan Optional berarti ini tidak benar.
garis ini

Saya tidak dapat menambahkan string yang diketik 'non-NUI' ke daftar ini

masuk akal dari sudut pandang Anda karena Anda harus secara eksplisit memasukkan String menjadi Optional<String> , yang saya lihat sesuai keinginan dan Anda anggap rusak. Karena tidak ada kesempatan bahwa Java menambahkan sistem yang mirip dengan implisit scala (yang akan menyelesaikan ini dalam arti global [tidak spesifik hanya untuk nullability]), ini adalah akhir yang cukup besar.

Dengan pengeditan ini, saya selesai dengan ini, dan terima kasih atas waktu Anda.

Yah, saya ingin menulis tanggapan yang panjang dan mendalam pada bagian di mana @rzwitserloot membalas posting saya, tetapi saya telah melihat orang lain telah mencoba sebelum saya. Dan saya ragu saya akan melakukan yang lebih baik.

@ ayush-finix, @michaelboyles, terima kasih.

@rzwitserloot

Saya hanya akan menanggapi satu hal: Anda sepertinya berpikir tidak ada pengembang yang pernah menggunakan Opsional, tetapi sejauh ini semua tim tempat saya bekerja memiliki pengembang begitu saja. Biasanya banyak.

Itu tergantung pada ekosistem tempat Anda berada.

Ketika masih terjebak dalam tim kuno berbasis java-ee, ya, Optional tampaknya tidak mendapatkan daya tarik sebanyak proyek berbasis Spring Boot/Quarkus yang lebih modern. Dalam kasus-kasus itu Anda bertemu dengan orang-orang pemarah yang tidak menyukainya.
Tapi di tim muda modern? Saya telah melihat seluruh arsitektur aplikasi yang mengamanatkan oworld.

Dan lombok. Terutama lombok. Karena kombinasi tersebut memecahkan banyak masalah yang Anda miliki ketika Anda ingin mengembangkan aplikasi dengan cepat dengan cara yang gesit. Lombok menangani boilerplate, Optional dan Streams menangani pemeriksaan nol yang hampir tak ada habisnya yang harus Anda lakukan di semua tempat. Anda sedang melihat pengurangan besar-besaran dalam LOC yang diperlukan untuk menulis bahkan hal-hal yang paling sederhana.

Terus terang, saya merasa heran bahwa keberatan utama Anda tampaknya diselesaikan di sekitar kasus sudut misterius di mana Anda ingin melakukan pengetikan campuran dari koleksi generik. Membutuhkan sesuatu seperti itu terjadi apa, mungkin sekali dalam seratus proyek?

Pengembangan aplikasi dunia nyata dari API dunia nyata bukan tentang memiliki metode mewah seperti itu. Ini tentang menangani kompleksitas sejuta kasus sudut, dan hanya menghapus nol dari persamaan membantu secara signifikan di sana. Di atas segalanya, itulah mengapa orang ingin menggunakannya. Deklarasikan null anathema, singkirkan sesegera mungkin sehingga logika bisnis inti Anda bisa serumit yang seharusnya tanpa harus berurusan dengan null factoring sebagai pengganda kompleksitas.

Ini bukan fanatisme. Itu bukan ideologi. Ini tentang memecahkan masalah dunia nyata di mana Anda harus menemukan logika aplikasi di antara 10.000 pemeriksaan nol dan bahkan kemudian tidak dapat memastikan apa pun yang Anda tangani saat ini dapat atau tidak dapat menjadi nol dan oleh karena itu, perlu pemeriksaan nol lagi.

Anda sepertinya berpikir tidak ada pengembang yang pernah menggunakan Opsional, tetapi sejauh ini semua tim tempat saya bekerja memiliki pengembang begitu saja. Biasanya banyak.

Tidak; Saya pikir para pengembang itu keliru, dan sedang menggali lubang dengan harapan, pada akhirnya, jika saja mereka menggali cukup lama, Anda akan melihat siang hari lagi. Kecuali, mereka menggali, dan lombok tidak akan memberi mereka sekop.

Itu tergantung pada ekosistem tempat Anda berada.

Program java yang jarang menggunakan java.* dan tidak menggunakan perpustakaan lain sama sekali adalah satu ekosistem di mana melakukan sesuatu seperti memiliki metode Optional<T> getX() adalah hal yang masuk akal. Itu kasus penggunaan yang terlalu eksotis untuk dianggap sebagai boilerplate. Ada lagi yang kembali ke masalah 'Anda hanya menggali lebih dalam'.

Saat masih terjebak di tim kuno berbasis java-ee

Lihat, __you__ tampaknya berpikir bahwa _not_ menggunakan opsional adalah 'kuno'.

Opsional dan Aliran menangani pemeriksaan nol yang hampir tak ada habisnya yang harus Anda lakukan di semua tempat.

Apa yang kamu bicarakan?

Anda tidak bisa menghindari pemeriksaan NUI karena Anda menggunakan Opsional. Sebaliknya: Karena varians dihilangkan saat menggunakan opsional, Anda mendapatkan _lebih banyak_ darinya.

Opsional memungkinkan untuk menentukan pada waktu penulisan/kompilasi panggilan API mana yang mungkin mengembalikan __NUI__ atau tidak. Kode versus yang tidak menggunakan opsional, di mana informasi ini masih disampaikan, tetapi, Anda harus membaca dokumen. Dengan demikian, Optional memberi Anda kombinasi 'membaca dokumen melalui dialog pelengkapan otomatis' (yang merupakan fitur hebat untuk dimiliki), dan pemeriksaan waktu kompilasi/waktu tulis.

Tidak ada yang mengurangi jumlah pemeriksaan nol yang Anda lakukan, kecuali jika Anda berbicara tentang 'pemeriksaan nol defensif', di mana Anda memanggil metode dan Anda tidak tahu apakah itu bisa mengembalikan nol atau tidak, jadi Anda memasukkan cek nol.

"Dokter sakit saat saya tekan di sini!" "Yah berhenti melakukan itu kalau begitu". Jangan menulis cek nol defensif. Jika Anda tidak yakin apakah API dapat mengembalikan null, itu berarti Anda tidak tahu apa artinya null. Jangan menulis kode untuk menangani kasus yang tidak Anda pahami kecuali kode tersebut mogok dan masuk log. NPE akan mogok dan masuk untuk Anda.

Anda sedang melihat pengurangan besar-besaran dalam LOC yang diperlukan untuk menulis bahkan hal-hal yang paling sederhana.

[rujukan benar-benar BENAR-BENAR dibutuhkan]. Seorang fanatik cenderung menggunakan hiperbola yang tidak dapat dipalsukan. Apa kau kasar? __Hentikan itu__. Berhentilah membuat klaim konyol berdasarkan keinginan dan unicorn. Jika kehadiran null menambahkan "LOC besar-besaran", Anda salah melakukannya.

Saya merasa aneh bahwa keberatan utama Anda tampaknya diselesaikan di sekitar kasus sudut misterius

Keberatan utama saya adalah bahwa Opsional tidak dapat diperkenalkan ke ekosistem Java tanpa menghapus hampir semua perpustakaan di keberadaan cerita dan panjang Java. Fakta bahwa Anda belum mengetahuinya dari diskusi membuat saya merasa kuat bahwa Anda tidak terlalu mempertimbangkan masalah dan hanya berteriak frustrasi.

Saya mengerti bahwa Anda frustrasi. Saya mencoba membantu Anda dengan menjelaskan berbagai hal. Rupanya, itu tidak berfungsi.

hanya menghapus nol dari persamaan membantu secara signifikan di sana

Juga, jika kita hanya ingin program menjadi ada, itu akan sangat membantu.

Anda tidak dapat menghapus NUI dari persamaan. Itu melekat dalam masalah yang coba dipecahkan oleh pemrograman. Tentu, Anda dapat memecahkan NUI dalam bentuk yang berbeda. Itu tidak membuat Anda mendekati keuntungan mistis yang tampaknya Anda pikir akan terjadi. Anda hanya menendang kaleng di jalan.

Nyatakan laknat nol, usir sesegera mungkin

Ini bukan fanatisme. Itu bukan ideologi.

TERTAWA TERBAHAK-BAHAK.

Saya telah menyempurnakan pemikiran saya tentang ini di wiki: null: Hanya puncak gunung es

Ini membahas banyak sekali kesalahpahaman yang diklaim di sini. Beberapa tanpa urutan tertentu:

@ayush-finix Di mana saya bisa melihat pembongkaran penuh yang Anda rujuk untuk pemahaman saya sendiri?

Saya tidak dapat menemukan makalah, jadi saya menulisnya sendiri, saya kira

@ayush-feniks Bagaimana kita membahas Opsional dalam ruang hampa?

Seperti ini.

@randakar Deklarasikan null laknat, usir secepatnya

Ini membingungkan NUI-the-reference-value dan NUI-the-concept, atau mungkin NUI-the-reference-value dan NUI-the-type-tag. Artikel wiki akan membantu.

Anda sepertinya berpikir tidak ada pengembang yang pernah menggunakan Opsional, tetapi sejauh ini semua tim tempat saya bekerja memiliki pengembang begitu saja. Biasanya banyak.

Tidak; Saya pikir para pengembang itu keliru, dan sedang menggali lubang dengan harapan, pada akhirnya, jika saja mereka menggali cukup lama, Anda akan melihat siang hari lagi. Kecuali, mereka menggali, dan lombok tidak akan memberi mereka sekop.

Semakin jauh saya menggali semakin saya suka di mana saya berakhir. Mungkin Anda harus mencobanya kapan-kapan.
Dengan serius. Cobalah kapan-kapan. Jalankan proyek, sebaiknya sesuatu di dunia boot musim semi, mulailah menggunakannya dengan segala cara yang Anda benci, dan kemudian lihat di mana Anda berakhir. Dan kemudian, baru kemudian, evaluasi dengan jujur ​​masalah apa yang akhirnya Anda alami.

Itu tergantung pada ekosistem tempat Anda berada.

Program java yang jarang menggunakan java.* dan tidak menggunakan perpustakaan lain sama sekali adalah satu ekosistem di mana melakukan sesuatu seperti memiliki metode Optional<T> getX() adalah hal yang masuk akal. Itu kasus penggunaan yang terlalu eksotis untuk dianggap sebagai boilerplate. Ada lagi yang kembali ke masalah 'Anda hanya menggali lebih dalam'.

Java, Spring Boot, hibernate, jackson, jambu biji, lombok, JPA, apache commons, junit, mockito, diyakinkan kembali. Minimal .
Dan saya menggunakan Optional<> sebagai nilai bidang karena menurut saya itu hanya wadah yang persis sama dengan kelas koleksi mana pun.

Saat masih terjebak di tim kuno berbasis java-ee

Lihat, Anda tampaknya berpikir bahwa _not_ menggunakan opsional adalah 'kuno'.

Itu karena itu. Ini adalah pemikiran gaya Java 6.

Opsional dan Aliran menangani pemeriksaan nol yang hampir tak ada habisnya yang harus Anda lakukan di semua tempat.

Apa yang kamu bicarakan?

Cuplikan diposting di sini: https://github.com/rzwitserloot/lombok/issues/1957#issuecomment -740239532
Itu kenyataan. Banyak programmer buruk di sekitar yang mengacaukan null dengan kosong. Seluruh kerangka kerja seperti JAXB yang menginisialisasi bidang dalam model dengan nol, dan kemudian Anda berakhir di basis kode di mana setengah kode terdiri dari mentah ini.

Anda tidak bisa menghindari pemeriksaan NUI karena Anda menggunakan Opsional. Sebaliknya: Karena varians dihilangkan saat menggunakan opsional, Anda mendapatkan _lebih banyak_ darinya.

Bagaimana mengurangi jumlah kemungkinan nilai yang dapat diambil suatu bidang meningkatkan kompleksitas program?
Karena itulah pendekatannya di sini.

Opsional memungkinkan untuk menentukan pada waktu penulisan/kompilasi panggilan API mana yang mungkin mengembalikan NUI atau tidak. Kode versus yang tidak menggunakan opsional, di mana informasi ini masih disampaikan, tetapi, Anda harus membaca dokumen. Dengan demikian, Optional memberi Anda kombinasi 'membaca dokumen melalui dialog pelengkapan otomatis' (yang merupakan fitur hebat untuk dimiliki), dan pemeriksaan waktu kompilasi/waktu tulis.

"Anda harus membaca dokumen" dalam program 600 file yang tidak memiliki atau hampir tidak memiliki dokumentasi? Jangan membuatku tertawa.
Anda tidak selalu memiliki kemewahan itu. Terkadang Anda memiliki kode yang dibuat secara otomatis untuk ditangani yang tidak memberi Anda kemewahan itu. Terkadang Anda berakhir di proyek lama dan Anda harus membersihkan semuanya satu langkah, satu cek nol, pada satu waktu.

Pada titik mana pemeriksaan waktu kompilasi adalah satu-satunya pilihan Anda, dan a

Optional.ofNullable(getFoo()).map(foo -> foo.getBar()).map(bar -> bar.getFinalValue()).orElse(defaultValue)

adalah satu-satunya cara yang masuk akal untuk menghadapinya.
Yang tentu saja, menyiratkan banyak pemeriksaan nol, tetapi saya tidak lagi harus secara eksplisit menulis setiap satu dari mereka.

Tidak ada yang mengurangi jumlah pemeriksaan nol yang Anda lakukan, kecuali jika Anda berbicara tentang 'pemeriksaan nol defensif', di mana Anda memanggil metode dan Anda tidak tahu apakah itu bisa mengembalikan nol atau tidak, jadi Anda memasukkan cek nol.

"Dokter sakit saat saya tekan di sini!" "Yah berhenti melakukan itu kalau begitu". Jangan menulis cek nol defensif. Jika Anda tidak yakin apakah API dapat mengembalikan null, itu berarti Anda tidak tahu apa artinya null. Jangan menulis kode untuk menangani kasus yang tidak Anda pahami kecuali kode tersebut mogok dan masuk log. NPE akan mogok dan masuk untuk Anda.

Saya tidak perlu menulis cek nol defensif jika semua data yang masuk dari luar sudah dikemas dengan baik di bidang Opsional.

Itulah dunia ideal yang ingin saya tuju. Bidang foo adalah opsional, bilah tidak, saya tahu saat itu juga bahwa foo bisa kosong dan saya harus menghadapinya entah bagaimana. Langkah selanjutnya adalah menghadapinya, sedini mungkin.

Bidang beranotasi juga berfungsi untuk itu, tetapi a) Anda sepertinya lupa tidak setiap proyek memiliki Kerangka Pemeriksa di dalamnya. Atau kapasitas untuk mengonfigurasinya, dan b) sama sekali tidak eksplisit. IDE hanya dapat membantu Anda sedikit, sedangkan dengan versi kode, kebutuhan untuk menanganinya sudah jelas di muka.

Anda sedang melihat pengurangan besar-besaran dalam LOC yang diperlukan untuk menulis bahkan hal-hal yang paling sederhana.

[rujukan benar-benar BENAR-BENAR dibutuhkan]. Seorang fanatik cenderung menggunakan hiperbola yang tidak dapat dipalsukan. Apa kau kasar? Potong itu . Berhentilah membuat klaim konyol berdasarkan keinginan dan unicorn. Jika kehadiran null menambahkan "LOC besar-besaran", Anda salah melakukannya.

Proyek terakhir saya turun 50% dalam hal total baris kode yang diperlukan setelah saya melakukan konversi ke lombok, optionals dan streams. Saya berharap yang saya saat ini (yang jauh, jauh lebih buruk) turun lebih dari itu.
Sejujurnya, saya dapat dengan mudah menyalahkan sebagian besar dari itu pada faktor-faktor lain.
Tapi lihat rangkaian pemanggilan .map() di bagian atas. Setiap baris menghemat 2 dari 3 baris yang diperlukan untuk versi if( foo != null ) {} . Jika Anda memiliki cukup dari itu, itu bertambah. Dan naik.

Saya merasa aneh bahwa keberatan utama Anda tampaknya diselesaikan di sekitar kasus sudut misterius

Keberatan utama saya adalah bahwa Opsional tidak dapat diperkenalkan ke ekosistem Java tanpa menghapus hampir semua perpustakaan di keberadaan cerita dan panjang Java. Fakta bahwa Anda belum mengetahuinya dari diskusi membuat saya merasa kuat bahwa Anda tidak terlalu mempertimbangkan masalah dan hanya berteriak frustrasi.

Saya merasa sudut pandang saya dianiaya. Saya disebut 'fanatik' tanpa alasan yang jelas. Saya tidak mengancam akan membakar Anda di tiang pancang, bukan?

Dan untuk 'usang setiap perpustakaan' - eh, banyak perpustakaan sudah usang. Jaxb sudah usang. Serialisasi sudah usang. Kelas Tanggal sudah usang. Neraka, semuanya menjadi usang, jika Anda menunggu cukup lama. Apa gunanya?
Opsional tidak memaksa perpustakaan tersebut untuk berubah. Waktu tidak. Berubah atau mati. Itulah hidup.

Tapi sementara itu, perpustakaan saya lakukan menggunakan tampaknya sebagian besar tidak punya masalah dengan itu. Kecuali, Anda tahu, yang tidak berubah seiring waktu. Lihat daftar itu di atas? Hampir semuanya ada di sana karena mendukung alur kerja saya, dan ya, kebanyakan dari mereka menambahkan dukungan untuk Opsional dalam beberapa cara, bentuk, atau bentuk.

Jadi mworld sudah ada di sini. Ini benar-benar.

Ironisnya - Lombok sebagian besar tidak harus mendukungnya. Kecuali untuk permintaan fitur khusus ini (yang bahkan tidak saya dukung. Tidak juga) lombok tidak perlu tahu.

Saya mengerti bahwa Anda frustrasi. Saya mencoba membantu Anda dengan menjelaskan berbagai hal. Rupanya, itu tidak berfungsi.

Hal yang membuat saya frustrasi adalah penganiayaan terhadap sudut pandang saya. Seluruh "Opsional adalah anti-pola" bs. Sejujurnya saya tidak bisa melihat bagaimana mencoba memecahkan masalah dengan menerapkan tingkat tipuan baru dalam bentuk kelas kontainer tiba-tiba menjadi masalah. Collection<Foo> foo baik-baik saja, Optional<Foo> foo apakah iblis? Dari mana sudut pandang itu berasal?
Sementara itu, saya benar - hal yang persis sama kecuali kurang baik? Cara yang bagus untuk membuat diri Anda merasa superior, tetapi bukan argumen yang bagus.

Saya tahu Anda mencoba menjelaskan, tetapi yang paling sering saya dengar adalah Anda ingin tetap menggunakan null dan menangani situasi di mana nilai null dan non-null dapat dicampur secara bebas. Namun saya tidak. Saya ingin mengganti null dengan sesuatu yang javac sebenarnya mampu menangkap untuk saya, dengan mengatakan null bukan hanya sebuah nilai. Saya tidak bisa mengetik getFoo().getBar().getRealValue() tanpa mempertaruhkan pengecualian nullpointer jika salah satu dari ini berpotensi mengembalikan nol. Saya harus memikirkannya , ketika saya sudah memiliki ruang kepala yang terbatas untuk memikirkannya. Sebagai gantinya, saya ingin berpikir tentang memecahkan masalah pelanggan saya, dan getFoo() mengembalikan opsional adalah cara yang tepat untuk memperjelas hal ini mungkin tidak benar-benar ada dalam model apa pun yang saya kerjakan, sementara juga memberi saya alat untuk menangani dengan itu dalam bentuk berbagai metode fungsional kelas itu.

Dan sungguh, saya tidak peduli dengan politik. Jika dunia anotasi NUI tiba dan menyelesaikan masalah, saya akan dengan senang hati menggunakannya.
Sampai saat itu, Anda dapat membongkar Opsional dari jari mati dingin saya, yang tidak memecahkan masalah, hari ini.

hanya menghapus nol dari persamaan membantu secara signifikan di sana

Juga, jika kita hanya ingin program menjadi ada, itu akan sangat membantu.

Heh, jangan kaget jika bagian terakhir itu menjadi kenyataan. Saya telah melihat pembicaraan tentang bantuan pengkodean yang digerakkan oleh AI menjadi sesuatu ..

Anda tidak dapat menghapus NUI dari persamaan. Itu melekat dalam masalah yang coba dipecahkan oleh pemrograman. Tentu, Anda dapat memecahkan NUI dalam bentuk yang berbeda. Itu tidak membuat Anda mendekati keuntungan mistis yang tampaknya Anda pikir akan terjadi. Anda hanya menendang kaleng di jalan.

Saya tidak ingin menghapusnya, saya ingin itu menjadi pengecualian yang menonjol saat itu adalah sebuah kemungkinan. Dan kemudian menanganinya segera.

Nyatakan laknat nol, usir sesegera mungkin

Ini bukan fanatisme. Itu bukan ideologi.

TERTAWA TERBAHAK-BAHAK.

Anda bisa tertawa tapi itu sangat praktis. Saya membuatnya terdengar seperti teologi tetapi ini hanyalah cara untuk mengurangi kompleksitas implisit yang tidak terlihat dari ruang masalah dengan membuat pengecualian menjadi eksplisit.

Saya telah menyempurnakan pemikiran saya tentang ini di wiki: null: Hanya puncak gunung es

Terima kasih.

Izinkan saya menyatakan di sini, sebagai catatan, bahwa saya sangat menghargai Anda melakukan ini. Meskipun frustrasi. Meskipun berbicara satu sama lain melalui jendela teks, bukan untuk kenyataan.

Saya mengerti berapa banyak waktu yang Anda butuhkan, belum lagi energi, dan saya mengerti itu agak menyebalkan.
Sejujurnya saya tidak tahu bagaimana cara mendapatkan halaman yang sama dengan Anda tentang masalah ini, tetapi upaya ini dihargai.

Satu hal yang akan saya katakan adalah saya lebih suka tidak harus membubuhi keterangan semuanya dengan @NotNull . Itu harus menjadi default tersirat, jangka panjang, dan @Nullable pengecualian.

@randakar Deklarasikan null laknat, usir secepatnya

Ini membingungkan NUI-the-reference-value dan NUI-the-concept, atau mungkin NUI-the-reference-value dan NUI-the-type-tag. Artikel wiki akan membantu.

Saya pasti mengacu pada nol, nilai referensi. Saya sendiri tidak peduli dengan NUI itu sendiri. Hanya tentang menghadapinya hari ini , dalam arti yang sangat praktis, daripada di masa depan dunia yang samar-samar.

Dan sungguh, serius, saya tidak berpikir langit akan jatuh dengan orang-orang yang menggunakan kelas Optional seperti yang (tampaknya) tidak dimaksudkan. Ini sudah berfungsi hari ini dengan baik, di mworld.

Satu- satunya permintaan yang saya buat adalah untuk menghentikan penganiayaan. Berhentilah menyebut ini anti-pola ketika alur penalaran ini sepenuhnya sah, bahkan jika Anda merasa itu salah arah. Berhenti bertindak semua superiour (dan untuk catatan: ini kebanyakan ditujukan galeri kacang, daripada Anda - di mana saya tahu beberapa komentator tiket lainnya harus menonton) tentang bagaimana buruk dan jelek Opsional adalah dan karena itu betapa bodohnya orang-orang harus mengusulkan ini. Berhenti menyebut kami fanatik. (Terutama ketika saya bisa membuat kasus yang cukup bagus, kebalikannya sebenarnya benar.)
Itu membuat Anda merasa baik tentang diri sendiri, mungkin. Tapi itu tidak membantu. Anda mendorong orang lain ke dalam lumpur hanya untuk membuat diri Anda merasa baik.
Saya sangat serius, karena saya menjalaninya.

Ini tidak jelek. Ini adalah cara yang indah dan sederhana untuk menangani masalah yang sangat praktis yang muncul di mana-mana. Tidak diperlukan dependensi atau anotasi tambahan. Tidak perlu membubuhi keterangan dari semua bidang dan argumen metode Anda. Hanya satu standar pengkodean dan Anda selesai.

Bagaimana mengurangi jumlah kemungkinan nilai yang dapat diambil suatu bidang meningkatkan kompleksitas program?

Anda tidak. A <strong i="7">@Nullable</strong> String dapat menampung semua kemungkinan nilai string dan null . Optional<String> dapat menampung semua kemungkinan nilai string dan Optional.none() . Anda tidak mendapatkan apa-apa di sisi referensi. Satu-satunya keuntungan penawaran opsional yang Anda dapatkan adalah dalam pengecekan tipe.

Saya ingin itu menjadi pengecualian yang menonjol saat itu adalah kemungkinan.

anotasi nullity juga mencapai hal ini, lebih kuat, dan dapat diperkenalkan tanpa merusak pustaka yang ada.

Satu hal yang akan saya katakan adalah saya lebih suka tidak perlu membubuhi keterangan semuanya dengan @NotNull.

Anda jelas belum menggunakan pustaka nulitas berbasis anotasi ini. Yang sedikit kaya, apa dengan paragraf pembuka Anda di posting Anda sebelumnya. Itu tidak perlu sama sekali.

Saya membuatnya terdengar seperti teologi

Jadi Anda setuju bahwa Anda membuatnya terdengar seperti teologi, tetapi Anda marah kepada saya karena saya menggunakan istilah 'fanatik'. Mungkin Anda harus berhenti membuatnya terdengar seperti teologi.

Saya pasti mengacu pada nol, nilai referensi.

Oh bagus! Maka Anda sama sekali tidak membutuhkan Opsional sama sekali, dan satu-satunya pertanyaan yang tersisa untuk dijawab adalah mengapa Anda repot-repot berdakwah di utas ini. Opsional adalah untuk orang-orang yang menginginkan nilai referensi NUI tetapi ingin NUiness disampaikan dalam sistem tipe. Bukan untuk orang-orang yang menganggap NUI adalah laknat, untuk dibuang begitu saja. (Kata-kata mu).

Terima kasih banyak untuk wiki dan upaya yang dilakukan untuk menulisnya. Ini sangat jelas dan ringkas. Saya yakin Anda berharap itu akan menghentikan diskusi untuk saat ini, jadi saya tidak mengharapkan balasan apa pun di bawah ini. Hanya pernyataan penutup...

Saya pikir titik kunci ketidaksepakatan yang saya miliki dengan Anda adalah sehubungan dengan definisi Anda tentang kompatibilitas mundur dan bagaimana hal itu harus ditangani.

Tim JDK hampir tidak pernah membuat perubahan yang tidak kompatibel. Saya akan menyarankan bahwa sinonim dari kompatibel ke belakang adalah "perubahan yang tidak melanggar" ( semver tampaknya setuju dengan saya, meskipun tidak secara eksplisit, tetapi melalui implikasi dari salah satu FAQ). Opsional sangat jelas bukan perubahan yang melanggar. Semua kode yang berfungsi sebelum Opsional masih berfungsi sekarang; tidak ada yang rusak.

API ini sekarang sudah usang: Hanya saja salah, sekarang. Seharusnya public Optional<V> get(Object o)

Tentu saja, dan pendukung Opsional akan setuju dengan pernyataan itu. Itu salah menurut standar sekarang . Tetapi apakah itu berarti Peta rusak dengan diperkenalkannya Opsional. Yang terburuk yang dapat Anda katakan tentang antarmuka Peta "warisan" adalah bahwa ia tidak mengikuti konvensi modern (Anda dapat memperdebatkan sejauh mana penggunaan Opsional adalah konvensi di komunitas yang lebih luas, tetapi saya sedang berbicara tentang konvensi JDK sendiri, yang telah terbukti digunakan dan terus menggunakan Opsional dalam komponen baru).

memecah java menjadi dua tidak sepadan

Anda menyatakan ini seolah-olah itu belum terjadi. Opsional telah diperkenalkan, dan dilihat dari sejarah Java, tidak akan pernah dibatalkan. HttpClient dan akses memori asing menggunakannya. Yang terakhir sedang dalam pengembangan aktif; jika mereka menyadari bahwa mereka telah melakukan kesalahan, mereka akan berhenti menggunakannya sekarang.

Jadi dari fakta yang saya tahu, yang penulis JDK

• tidak berencana untuk merevisi misalnya antarmuka Peta
• secara aktif menggunakan Optional (di luar konteks Streams )

Saya dapat menyimpulkan beberapa hal. Yaitu, bahwa penulis JDK

• tidak apa-apa dengan Java dipecah menjadi dua
• berpikir bahwa Java yang dipecah menjadi dua sebenarnya lebih baik daripada yang kita miliki sebelumnya
• akan terus menggunakan Opsional, dan bahwa kesenjangan akan tumbuh lebih besar, setidaknya di JDK

Saya tidak bermaksud memasukkan kata-kata ke mulut siapa pun, tetapi saya pikir itu adalah kesimpulan yang masuk akal berdasarkan apa yang saya lihat Brian Goetz dan Stuart Marks katakan tentang masalah ini, dan bagaimana saya melihat JDK berkembang. Saya telah melihat mereka mengakui beberapa kesalahan tentang desain Optional, tetapi keberadaannya bukanlah salah satunya. Jika Anda memiliki bukti sebaliknya, tolong tunjukkan saya.

Saya tahu Anda menginginkan pernyataan yang dapat dipalsukan, tetapi ketiga hal ini hanyalah masalah pendapat. Pendapat saya adalah bahwa penulis JDK benar: Java lebih baik dengan Optional daripada tanpa itu, bahkan jika itu berarti dunia yang retak. Anda mungkin berharap bahwa NUI akan diselesaikan dengan lebih elegan, dan mungkin berharap suatu hari akan tetap demikian. Saya yakin Anda benar bahwa secara teknis hal itu mungkin saja terjadi. Tapi saya tidak ingin berurusan dengan kode omong kosong sementara saya bertahan untuk masa depan itu. Kami telah ditawari solusi yang berhasil* saat ini dan saya, serta banyak lainnya, sedang menggunakannya.

Saya tidak akan meremehkan pengaruh standar yang ditetapkan oleh JDK terhadap komunitas Jawa. Jika itu cukup baik untuk mereka, itu juga akan cukup baik untuk banyak pengembang Java.

Anda mungkin akan memperdebatkan sejauh mana "itu berfungsi", varians WRT, dll. Anda mungkin benar bahwa itu tidak optimal.

@michaelboyles Yang terburuk yang dapat Anda katakan tentang antarmuka Peta "warisan" adalah tidak mengikuti konvensi modern

Dengan kata lain, bahwa API Peta sekarang 'usang', bukan karena pilihannya sendiri, tetapi dipaksakan karena konvensi modern di negeri hipotetis unicorn dan keinginan Anda telah berubah. Saya tidak akan memperdebatkan apa arti kompatibilitas mundur dengan Anda - itu hanya omong kosong tentang kata-kata. Sangat jelas bahwa kepatuhan luas terhadap apa yang Optional coba lakukan berarti j.u.Map bermasalah. Apakah Anda menyebutnya 'mundur tidak kompatibel' atau 'usang' atau hanya 'tidak lagi sesuai dengan konvensi modern', __Saya tidak peduli kata apa yang Anda gunakan__ - itu buruk. Java memperkenalkan generik dan lambda dalam pembaruan, dan kedua pengenalan ini berusaha keras untuk memastikan bahwa API yang ada tidak terpengaruh sama sekali, atau, bahwa API yang ada dapat memperbarui ke 'konvensi modern' dengan cara yang kompatibel. .

Jelas bagi saya bahwa baik Anda maupun orang lain di utas ini tidak berhasil menemukan cara untuk membuat Optional terjadi tanpa merusak API seperti Map.get , dan __itu berakhir di sana untuk saya__. Opsional diveto sampai Anda dapat memperbaikinya.

bahwa penulis JDK

Salah satu penulis JDK yang paling produktif dan berwibawa adalah Brian Goetz. Anda dapat mencari di web untuk pendapatnya tentang Opsional. Anda __wildly__ salah memahami mereka jika menurut Anda penulis JDK siap untuk getter yang kembali opsional, atau bahwa mereka dengan sukarela mendaftar untuk membagi ekosistem JDK menjadi dua.

tapi saya pikir itu adalah kesimpulan yang masuk akal berdasarkan apa yang saya lihat Brian Goetz dan Stuart Marks katakan tentang masalah ini

Tidak, mereka bukan.

Saya tahu Anda menginginkan pernyataan yang dapat dipalsukan, tetapi ketiga hal ini hanyalah masalah pendapat.

Jadi mengapa Anda memposting? Ini adalah utas permintaan fitur, bukan pemungutan suara publik, seperti yang telah saya jelaskan. Saya tidak benar-benar tahu tempat yang baik untuk mengadakan diskusi ini, jadi saya membiarkan ini berlangsung untuk sementara waktu, tetapi, saya telah menjelaskan bahwa kita perlu menyeret ini kembali ke pernyataan yang dapat dipalsukan. Sudah berlangsung cukup lama - ini bukan tempatnya. Posting opini lebih lanjut tidak lagi diterima. Tunjukkan pada saya proposal yang disempurnakan, analisis komunitas, saran tentang bagaimana API yang ada dapat mengikuti tanpa merusak kompatibilitas atau merasa usang/ 'tidak lagi mengikuti konvensi modern' - tidak apa-apa.

@randakar menulis:

Saya tidak berperang melawan orang lain di sana. Hanya melawan nol, dalam kode saya sendiri. Itu bukan fanatisme, itu hanya menyeluruh.

Saya baru saja selesai menghapus banyak posting Anda dan lalu lintas yang disebabkannya di utas lain karena Anda berjuang untuk Opsional di dalamnya (dengan semua orang yang terlibat segera menembaknya sebagai tidak masuk akal, yang benar-benar membuat label fanatik itu menempel). Sangat disayangkan saya harus menggunakan ini, tetapi Anda dilarang dari masalah ini. Setiap komentar lebih lanjut dari Anda akan dihapus, jelas kami telah melampaui segala upaya untuk beralasan dan membangun sesuatu yang menyerupai permintaan fitur. Harap menahan diri dari perang salib untuk Opsional dalam masalah lain atau PR juga.

seluruh diskusi ini bermuara pada:

1. Salah satu bagian dari komunitas Java berpikir Optional tidak menambahkan nilai pada bahasa - hanya membuat segalanya lebih berantakan dan tidak konsisten dan hampir tidak pernah menjadi pengguna.
2. Bagian kedua dari komunitas Java berpikir Optional memberi mereka kode yang lebih bersih dan mereka ingin menggunakannya secara ekstensif.
3. Kedua kelompok ini sangat banyak dan memiliki argumen masing-masing.
4. @rzwitserloot apa yang harus digunakan posisi terdepannya di atas perpustakaan populernya untuk menegakkan pendapatnya tentang masalah ini di komunitas Java

@rzwitserloot dan kolaboratornya memberi kami perpustakaan yang bagus dan memiliki hak untuk melakukannya. Ini tidak mengurangi fakta bahwa kita harus bersyukur atas pekerjaan yang mereka lakukan.

Yang mengatakan kami juga dapat memiliki pendapat tentang sikap keras mereka tentang masalah ini. Saya pribadi berpikir itu agak tidak dewasa. Saya pernah menghindari Optional sekali juga, tetapi bagi banyak rekan kerja saya, itu benar-benar membuat mereka menulis kode yang lebih bersih dan lebih mudah dibaca. Sekarang saya selalu mengizinkan tim saya untuk memutuskan proyek demi proyek apakah mereka ingin menggunakan Optional dalam setiap metode yang mengembalikan nilai opsional atau haruskah kita menghindarinya di mana pun. Saya setuju dengan salah satu pendekatan selama itu akan konsisten di seluruh kode aplikasi.

Terlepas dari pendapat Anda @rzwitserloot, ada kemungkinan kompromi di sini. Jika Anda mengizinkan kami untuk - misalnya - menambahkan parameter global lombok.dreaded-optional-support=true (false secara default) dan mengizinkan kami menerapkan aturan berbeda untuk menghasilkan getter pada atribut @Nullable saat aktif (dan lainnya tambahan seperti ini). Maka kita akan baik-baik saja - Anda masih dapat menyatakan pendapat Anda tentang mengapa Optional buruk di semua bagian dalam dokumentasi.

Jika Anda tidak setuju dengan

Setiap orang yang ingin melihat dukungan Optional di lombok harus berhenti bicara dan mulai mengkodekan fork. Bicara itu murah, tulis kodenya. Kami bahkan dapat bersikap ramah tentang hal itu dan mencoba menjaga agar basis kode tetap sinkron dengan hanya menambahkan dukungan Optional dan merilis pustaka bernama lombok-with-optional . Di masa depan, statistik pakar akan memberi tahu opsi mana yang terbukti lebih berguna bagi pengembang.

untuk menggunakan posisinya sebagai pemimpin atas perpustakaannya yang populer untuk memaksakan pendapatnya tentang subjek tersebut di atas komunitas Jawa

Jelas ini perlu disebutkan. Ini adalah permintaan fitur untuk Project Lombok. Bukan forum umum.

Terlepas dari pendapat Anda @rzwitserloot, ada kemungkinan kompromi di sini.

Utas ini merupakan indikasi kuat bahwa itu tidak mungkin.

Jika Anda mengizinkan kami untuk - misalnya - menambahkan parameter global lombok.dreaded-optional-support=true

Saya tidak melihat bagaimana Anda dapat membuat janji untuk mempertahankan ini selama 10 tahun. Yang membuat intinya diperdebatkan: Tidak bisa.

Jika Anda tidak setuju dengan

Itu sepertinya kesimpulan yang tepat, ya.

Ayo @rzwitserloot , Opsional adalah tipe resmi Java dan Lombok adalah perpustakaan yang sangat berguna untuk menyelesaikan pengkodean boilerplate, itu saja! Jadi, mohon jangan salah menilai komunitas (yaitu audiens di utas ini) karena meminta dukungan Lombok untuk Opsional dan terserah pengguna akhir untuk memutuskan bagaimana mereka ingin menggunakannya. Bagaimana mendorongnya sebagai eksperimental dan melihat umpan balik dari komunitas?

Kami sangat menghormati pandangan dan argumen Anda, tetapi tipe Opsional adalah bagian dari JDK sejak lama dan sepertinya Lombok tidak bertanggung jawab untuk mengadvokasi bagaimana itu harus diadopsi atau tidak!

Teman-teman, mari santai!

@rzwitserloot Terima kasih atas perpustakaan yang sangat berguna ini! Dan terima kasih telah berbagi posisi Anda di null dan Optional . Saya sangat menghargai pendapat berdasarkan informasi yang didukung oleh analisis formal yang bijaksana seperti milik Anda.

Saya punya sedikit permintaan, dari satu kontributor Lombok ke kontributor lainnya. Silakan renungkan dan pertimbangkan sejenak: Apakah ada hal lain yang lebih penting bagi Anda selain nasib Optional ? Bagaimana dengan kebebasan dan pilihan pribadi yang kita semua nikmati untuk menciptakan apa yang kita inginkan—kebebasan yang memungkinkan Anda dan @rspilker menciptakan Lombok dan membantu jutaan orang lain berkreasi dengan lebih efisien?

Mari kita tinjau beberapa fakta:

1. Optional diperkenalkan ke bahasa 7+ tahun yang lalu.
2. Itu belum ditinggalkan.
3. Orang-orang menggunakannya.
4. Apakah orang menggunakan Optional adalah di luar kendali Anda.
5. Sejumlah besar pengguna Lombok secara manual menulis getter yang mengembalikan Optional .
6. Anda memiliki kekuatan untuk membuat mereka lebih produktif bahkan saat Anda terus berjuang melawan Optional .

Kami tidak meminta Anda untuk melakukan aborsi atau membuat kue untuk pernikahan gay. Kami hanya meminta Anda untuk membantu kami menghemat beberapa penekanan tombol (dan beberapa detik membaca kode boilerplate) hampir setiap hari di tempat kerja. 😄

Jika Optional tidak digunakan lagi suatu hari nanti, saya berjanji untuk tidak marah saat Anda menghentikan dukungan untuk getter Optional . Saya akan memuji kesuksesan Anda!