Autofixture: Pembebasan namespace

Bisa tolong jelaskan?

Saya akan mengatakan itu akan lebih baik hanya dengan using AutoFixture; daripada using Ploeh.AutoFixture;

03-03-2016 22:34 GMT+01:00 Nikos Baxevanis [email protected] :

Bisa tolong jelaskan?

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/AutoFixture/AutoFixture/issues/538#issuecomment -191973353
.

Sepertinya bagian Ploeh adalah sisa dari saat ini adalah pribadi
proyek hobi, atau sekadar bukti konsep, atau eksperimen... Bukan
lagi.

Ketika proyek mendapatkan lebih banyak daya tarik (yang tampaknya mungkin terjadi, karena
dunia .NET semakin tertarik ke arah DI), bisa bermanfaat untuk
bahkan memindahkan proyek untuk dimiliki oleh beberapa yayasan AutoFixture.

Tapi itu masalah lain, tentu saja.

03-03-2016 22:37 GMT+01:00 Björn Göransson bjorn.a. [email protected] :

Saya akan mengatakan itu akan lebih baik hanya dengan using AutoFixture; daripada using Ploeh.AutoFixture;

03-03-2016 22:34 GMT+01:00 Nikos Baxevanis [email protected] :

Bisa tolong jelaskan?

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/AutoFixture/AutoFixture/issues/538#issuecomment -191973353
.

Harap perbaiki saya jika ada motivasi teknis untuk saran ini, tetapi jika saya memahaminya dengan benar, ini sebagian besar tentang persepsi.

Memang benar saya menambahkan bagian _Ploeh_ ke sebagian besar kode yang saya terbitkan. AutoFixture memang dimulai sebagai proyek pribadi.

Mengubah semua ruang nama di AutoFixture akan menjadi perubahan besar, jadi itu bukan sesuatu yang bisa kita lakukan di AutoFixture 3, tapi kita bisa mempertimbangkannya untuk AutoFixture 4.

Apa pendapat orang tentang saran ini? /cc @moodmosaic @ecampudoglio @adamchester

Saya hanya pengguna autofixture dan tidak melihat gunanya untuk mengubahnya. Ada banyak hal berguna di blog Ploeh :)

Agak masuk akal dari sudut pandang pengguna baru, tapi jujur ​​itu juga bukan masalah. Mengimpor ruang nama biasanya dilakukan secara otomatis oleh IDE Anda.

Alias ​​impor Anda!

Saya tidak melihat ada yang salah dengan _Ploeh_ menjadi bagian dari namespace.

Lagi pula, ketika saya melihat _Ploeh_ saya tahu ini tentang sesuatu yang baik, dan kualitas yang baik.

Saya akan menyimpannya sebagai _Ploeh.AutoFixture_.

Saya pikir tidak apa-apa, "merek" publik adalah AutoFixture ... tidak masalah apa ruang nama itu.

Bukankah sama dengan Json.NET ? ruang nama dimulai dengan Newtonsoft.Json ...

Untuk referensi: Saya meminta komentar melalui Twitter: https://twitter.com/ploeh/status/705721775011848192

(Mungkin ada beberapa tanggapan yang tidak muncul di sini.)

Saya tidak melihat alasan _at all_ untuk mengubah namespace. Sebagai @moodmosaic keluar runcing , nama _Ploeh_ dikaitkan dengan kualitas dan pengerjaan begitu, persepsi-bijaksana, itu membuat banyak akal untuk tetap.

Juga, saya tidak berpikir ada yang salah dalam membiarkan sejarah proyek ditampilkan di namespace; itu adalah penghormatan kepada akar proyek dan penulis yang menyusun ide aslinya.

Saya setuju dengan @ecampudoglio. Pada catatan terkait, apa artinya _ploeh_?

Saya juga mengalami masalah dengan Json.NET diberi namespace sebagai Newtonsoft! ( :+1: @tsimbalar udah ngingetin ... )

@ecampudoglio , maksud saya adalah bahwa proyek itu sendiri telah mencapai titik kegunaan _dan_ keahlian sehingga tindakan menandatangani namespace menjadi berlebihan. Hal yang AutoFixture membuat itu tidak perlu.

@ploeh : "våga" ambil risiko!

Saya pikir itu bukan masalah. Tetapi OP dapat memotong proyek dan menghapus awalan yang menyinggung. Kemudian biarkan pengguna memutuskan apa yang mereka sukai.

Ya; hanya jika Ploeh sendiri akan memilih untuk menghapusnya, Anda akan menerimanya
melakukannya. Bukannya ada alasan lain untuk menyimpannya selain untuk
menyelaraskan diri dengan pendapatnya (potensial) untuk melakukan hal yang sama.

03-04-2016 18:13 GMT+01:00 Mike Mogosanu [email protected] :

Saya pikir itu bukan masalah. Tetapi OP dapat memotong proyek dan menghapus
awalan yang menyinggung. Kemudian biarkan pengguna memutuskan apa yang mereka sukai.

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/AutoFixture/AutoFixture/issues/538#issuecomment -192362828
.

Oke, komentar terakhir itu agak terlalu troll-y. Saya akan ulangi: Mungkin Ploeh berpikir bahwa waktunya telah tiba?

Mungkin sebagian besar pengguna autofixture tidak mempedulikannya?

Saya lebih suka menjaga namespace apa adanya.

Aku akan meninggalkannya. Ini berkontribusi pada 'keunikan' penamaan. Seseorang di masa depan masih dapat membuat Foo.AutoFixture, atau MS dapat membuat System.AutoFixture :)

Terima kasih, semuanya, atas tanggapan Anda!

Sekarang diskusi ini telah mereda, saya telah menghitung 'suara' dari sini dan tweet , dan menemukan bahwa 2 orang mendukung saran ini, sedangkan 10 orang ingin mempertahankan namespace seperti saat ini. Selain itu, beberapa komentar tidak menunjukkan preferensi tertentu, jadi saya tidak memasukkannya ke dalam penghitungan saya.

Namun, saya akan memberikan suara saya untuk menjaga namespace apa adanya, jadi itu sebenarnya 11 suara menentang saran ini.

Alasan yang paling penting adalah saya tidak menemukan keuntungan membuat perubahan lebih besar daripada biayanya.

Keuntungan melakukan perubahan, sejauh yang saya tahu, minimal. Saya memahami argumen tentang persepsi, dan saya tidak membantahnya. Namun, itu sepenuhnya subjektif. Sebagai contoh, saya adalah pengguna perpustakaan Unquote yang senang , dan itu tidak mengganggu saya sedikit pun bahwa saya harus mengimpor perpustakaan Swensen.Unquote .

Biaya perubahan juga minimal. Namun, itu berarti bahwa semua kode pengguna akan rusak. Perbaikan untuk itu akan sepele: orang hanya perlu menghapus Ploeh. dari arahan impor mereka. (Saya yakin beberapa jiwa yang ramah bahkan akan memberi tahu saya bahwa Resharper dapat melakukan ini secara otomatis, tetapi sekarang saya hanya berspekulasi.) Tetap saja, itu _adalah_ ketidaknyamanan bagi pengguna, tidak peduli seberapa kecil, jadi itu harus dijamin.

Keuntungan dan kerugian dalam melakukan perubahan itu kecil, jadi itu bukan keputusan yang mudah. Dalam kasus seperti itu, saya cenderung berbuat salah di sisi hati-hati: jangan membuat pengguna tidak nyaman tanpa alasan yang jelas. Namun, ini adalah panggilan yang cukup dekat sehingga saya meminta umpan balik dalam upaya untuk mengukur pandangan pengguna tentang masalah tersebut. Hasilnya, meskipun secara statistik tidak signifikan, tidak mengubah pendapat saya.

@bjorn-ali-goransson, saya ingin mengucapkan terima kasih telah memulai diskusi ini, yang menurut saya bermanfaat. Saya senang bahwa seseorang memiliki keberanian untuk menantang status quo; Anda harus terus melakukan itu.

Meskipun keputusan saya tidak berjalan seperti yang Anda inginkan, saya harap Anda menemukan bahwa saya telah memberikan pertimbangan yang adil.

@ploeh - Saya hanya ingin meluangkan waktu khusus untuk memuji Anda atas pendekatan kolaboratif yang Anda ambil dalam hal ini.

Jangan heran jika saya mengirim orang ke tiket ini untuk membantu memahami bagaimana wacana dalam pengembangan perangkat lunak harus dilakukan. Teknik Anda telah persis filosofi saya pada diskusi tentang hal-hal teknis.