Autofixture: Diskusi: Awalan namespace 'Ploeh'

Dibuat pada 2 Apr 2017  ·  32Komentar  ·  Sumber: AutoFixture/AutoFixture

Dengan membuka tiket ini saya ingin memahami posisi kami mengenai namespace 'Ploeh.AutoFixture' yang saat ini kami miliki di AutoFixture dan apa visi kami tentang hal itu di masa depan. Pertanyaan ini sudah muncul dan kami pasti akan bertemu lagi di masa depan :)

Ada 2 cara bagaimana kita bisa berperilaku - tetap seperti apa adanya atau hapus awalan Ploeh . Setiap opsi memiliki pro dan kontra ini.

Tetap apa adanya

Idenya adalah untuk menyimpan awalan Ploeh di semua ruang nama untuk saat ini, terlepas dari kenyataan bahwa Mark bukan pemilik repo lagi.

__Pro:__

  1. Itu akan mengabadikan investasi @ploeh ke dalam proyek ini karena jumlahnya cukup besar.
  2. Itu tidak akan membuat perubahan yang mengganggu selama migrasi ke v4 .

__Kekurangan:__

  1. Kepemilikan yang sangat tidak jelas. Seperti yang dikatakan Mark di sini , banyak orang masih berpikir bahwa dia adalah pemilik repositori. Jika kita mempertahankan awalan namespace, kebingungan ini akan tetap ada.
    Di sisi lain, jika kita menghapusnya - namanya tidak akan ada di semua ruang nama yang diimpor lagi, jadi setelah beberapa waktu kebingungan akan hilang.
  1. Kebingungan dari konsumen. Kelihatannya mirip dengan poin 1, tetapi perbedaannya adalah tidak semua orang tahu siapa Ploeh . Mungkin tidak jelas bagi konsumen baru (dan yang sudah ada) mengapa kami memiliki awalan yang tidak biasa ini :)

Ubah awalan

Pilihannya adalah mengubah semua file di semua proyek dan menghapus awalan Ploeh . Secara teknis itu mudah dilakukan, jadi pertanyaannya hanya tentang keputusan kami.

Pro dan kontranya sama dengan opsi _Keep as is_:

__Pro:__

  1. Kepemilikan. Jelas bahwa AutoFixture adalah organisasi mandiri yang mengelola proyek itu sendiri. Mark (Ploeh) tidak memimpin proyek lagi. Juga lebih sedikit orang akan berpikir bahwa proyek ini milik Mark.
  1. Ruang nama yang disederhanakan. Itu akan menghapus kata yang tidak perlu dari namespace, sehingga akan membuat impor namespace kurang bertele-tele.

__Kekurangan:__

  1. Ini akan menjadi perubahan besar karena semua orang yang bermigrasi ke v4 akan dipaksa untuk mengubah impor namespace. Juga, bisa terjadi bahwa nama tipe lengkap di-hardcode di suatu tempat sebagai string. Tentu saja, ini akan dilakukan hanya sekali dan mudah dilakukan, tetapi ada orang yang tidak melacak semua hal kepemilikan ini dan hanya menggunakan AF - itu akan sangat membosankan bagi mereka.

Pertama-tama saya ingin mendengar pendapat @ploeh tentang perubahan ini dan ke arah mana dia secara pribadi lebih suka. Anda, Mark, banyak berinvestasi di sini sehingga visi Anda penting.

Saya juga ingin melibatkan orang-orang dari tim inti: @ecampidoglio , @moodmosaic dan @adamchester.

Setelah kami memutuskan, kami akan memiliki masalah dengan keputusan kami, jadi nanti kami bisa meneruskan siapa saja yang bertanya/tidak setuju di sini :)

question

Komentar yang paling membantu

itu terlihat tidak berterima kasih terhadap Mark.

Jangan khawatir tentang itu. Terima kasih terbaik yang dapat Anda berikan kepada saya adalah menjaga AutoFixture tetap hidup. Jika Anda bisa melakukannya, saya telah berhasil menciptakan sesuatu yang layak dengan caranya sendiri. Beberapa hal bisa lebih memuaskan dari itu.

Semua 32 komentar

Sepengetahuan saya, sebagian besar proyek OSS memiliki namespace root yang identik dengan namanya, jadi saya tidak melihat masalah apa pun di sini. Karena ini akan menjadi perubahan besar, Anda hanya perlu meningkatkan versi utama.

👍 untuk mengubah namespace root menjadi AutoFixture dalam versi yang rusak.

Saya tidak keberatan menyimpan namespace Ploeh. Kepemilikan tidak berhubungan dan
namespace berubah pada hal-hal yang berfungsi dengan baik, mengapa ..?

Pada Minggu, 2 April 2017 pukul 14:04 Adam Ralph [email protected] menulis:

👍 untuk mengubah namespace root ke AutoFixture dalam versi yang melanggar.


Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di GitHub
https://github.com/AutoFixture/AutoFixture/issues/745#issuecomment-290999395 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AAwCv_G4V_0nKgVTPpSAOpmMAQ8BMJQ6ks5rr9UpgaJpZM4Mw1jd
.

Saya setuju dengan analisis keseluruhan (pro dan kontra yang diuraikan di atas).

Seperti yang telah dicatat oleh beberapa orang di sini, mengubah namespace akan menjadi perubahan besar. OTOH, mengubah namespace antara versi 3 dan versi 4 tampaknya setidaknya dapat dipertahankan, karena perubahan tata kelola. Akan jauh lebih sulit untuk mempertahankan penghapusan 'Ploeh' antara versi 4 dan versi 5.

Jika Anda ingin menghapus 'Ploeh' dari namespace, sekaranglah saatnya untuk melakukannya.

@ploeh Terima kasih atas jawabannya. Satu pertanyaan lagi untuk Anda - opsi mana yang Anda sukai secara pribadi? :) Saya tahu bahwa ini pertanyaan yang agak rumit, tetapi saya percaya bahwa saya bukan satu-satunya yang penting, karena Anda adalah seorang pendiri (atau salah satu pendiri, saya tidak yakin :flushed:).

Saya lebih suka Anda mencapai keputusan yang Anda yakini adalah yang terbaik untuk proyek yang bergerak maju

Dari perspektif eksternal, saya dapat mengatakan bahwa memiliki namespace Ploeh.Autofixture membuat penggunaan pertama saya dari perpustakaan sedikit lebih sulit karena namespace tidak terkait dengan nama paket atau proyek di sini di GitHub.

Agak mengejutkan untuk mengetik using Auto... dan menerima daftar kosong dari Intellisense.

Saya setuju dengan @Kralizek.
Tetapi masalah dengan mengganti nama proyek menjadi Fixture.Net (walaupun secara pribadi saya akan mendukung langkah ini) berarti melanggar dengan cukup luas dan terkenal di nama komunitas .NET.

Setuju dengan apa yang ditulis @ploeh

Jika Anda ingin menghapus 'Ploeh' dari namespace, sekaranglah saatnya untuk melakukannya.

Tentu saja, ini hanya dapat terjadi di cabang v4 .

Perubahan Namespace agak Mudah, Cari & Ganti dan Anda selesai dalam kode sumber Anda sendiri.

Masalahnya adalah dengan nuget jika paket lain menggunakan AutoFixture dan tidak memiliki pembatas Versi yang tepat di nuspec maka ini juga akan rusak. Namun untuk saat ini pengguna dapat dengan mudah kembali ke AutoFixture 3.x. Ini dapat diatasi di Dokumentasi, Rilis posting Blog atau apa pun.

Saya untuk menghapus Ploeh dari Namespace, saya tidak pernah suka Personal Namees di Namespace, melakukan ini di awal proyek saya, membenci saya karena melakukan itu;)

jika paket lain menggunakan AutoFixture dan tidak memiliki pembatas Versi yang tepat di nuspec maka ini juga akan rusak

Saya tidak akan mengkhawatirkannya. Masalah yang sama ada untuk setiap versi yang rusak. Jika paket hilir memilih untuk tidak menempatkan batas atas eksklusif pada versi mayor berikutnya misalnya <dependency id="AutoFixture" version="[3.0,4.0)" /> , maka mereka mengundang masalah ini setiap kali versi utama AutoFixture dirilis.

@abatishchev Apakah Fixture.Net berasal dari diskusi lain? Saya akan sangat senang hanya dengan mengubah namespace menjadi AutoFixture

@moodmosaic Bisakah Anda juga menambahkan posisi Anda tentang ini? Saya percaya bahwa kita perlu memiliki semua pendapat pengelola inti untuk membuat keputusan akhir.

Ι lakukan sudah.

@moodmosaic Saya melihat jawaban itu, tetapi saya tidak yakin saya mendapatkan posisi Anda. Apakah Anda memilih untuk mempertahankan namespace atau menghapusnya? :)

Saya memilih untuk menyimpannya. Kurang mengganggu.

Mengapa melakukan hal-hal yang mengganggu membuat Anda khawatir? Banyak orang yang meminta perubahan ini.
Bahkan kurang mengganggu akan meninggalkan proyek apa adanya, tidak membuat perubahan sama sekali. Tapi bukan itu maksud dari semua proses ini, bukan?
Saya pribadi ingin melihat Anda melanjutkan perubahan ini.

@moodmosaic saya melihat bahwa jawaban, tapi saya tidak yakin saya mendapat posisi Anda.

Saya akan baik-baik saja, jika namespace root diganti namanya menjadi hanya AutoFixture di v4 .

Sementara saya mendukung suara saya Ploeh , saya baik-baik saja dengan itu dihapus jika itu yang diinginkan kebanyakan orang.

Mengingat perubahan kepemilikan, saya melihat bagaimana masuk akal untuk proyek ke depan dan waktunya tepat. Pada titik ini, satu-satunya argumen balik yang bisa saya kemukakan hanyalah berdasarkan emosi.

@ecampidoglio , saya juga mengalami emosi, tetapi saya pikir itu lebih 'benar' hanya dengan _AutoFixture_ di v4...

@moodmosaic Terima kasih atas jawabannya, hal yang sama sebenarnya terjadi pada saya. Semakin saya mempelajari proyek ini, semakin saya melihat dan menyadari jumlah pekerjaan yang Mark lakukan di sini - sejumlah besar diskusi yang berbeda, perubahan kecil, balasan pada SO, dll. Menjadi semakin sulit untuk membuat keputusan untuk memangkas awalan - itu terlihat tidak berterima kasih terhadap Mark.

Dari sisi lain, saya mengerti bahwa awalan AutoFixture yang sederhana akan terlihat jauh lebih baik dan konsisten. Sebenarnya, tidak ada yang mengerikan di sini, karena nama Mark akan tetap ada dalam daftar penulis paket, wiki, masalah.. Dengan @adamchester dan @ecampidoglio memilih untuk mempertahankan awalan, semakin sulit untuk membuat keputusan - banyak hal-hal emosional hadir di sini. Kemungkinan, kita harus memisahkan aspek emosional dan tidak mencampuradukkannya. Secara pribadi, saya tidak memperlakukan pemangkasan namespace sebagai tindakan depresiasi pekerjaan Mark - bagi saya alasannya adalah pembersihan rumah murni. Saya masih akan sangat berterima kasih padanya bahkan jika awalannya tidak ada.

Namun mengingat bahwa saya mulai mengerjakan proyek terlambat (dan tidak ada yang mengenal saya), saya merasa bahwa saya tidak dapat sepenuhnya memahami kontribusi Mark dan, oleh karena itu, kata terakhir pasti sampai ke kontributor inti.

@zvirja Saya pikir Anda salah paham dengan komentar saya sebelumnya :

Saya baik-baik saja dengan itu dihapus jika itu yang diinginkan kebanyakan orang.

Jadi, ya, saya lebih suka menyimpannya tetapi saya setuju dengan namespace AutoFixture di v4. 😉

Pendapat saya pada dasarnya sama dengan @ecampidoglio - Saya lebih suka menjaga namespace apa adanya hanya untuk menghindari gangguan yang tidak perlu bagi pengguna, tetapi saya setuju dengan mengubahnya menjadi hanya AutoFixture di v4.

itu terlihat tidak berterima kasih terhadap Mark.

Jangan khawatir tentang itu. Terima kasih terbaik yang dapat Anda berikan kepada saya adalah menjaga AutoFixture tetap hidup. Jika Anda bisa melakukannya, saya telah berhasil menciptakan sesuatu yang layak dengan caranya sendiri. Beberapa hal bisa lebih memuaskan dari itu.

Terima kasih atas jawabannya, Markus!

Mengingat semua balasan di atas dan mengingat bahwa tim inti tidak keberatan mengubah namespace, saya akan menambahkan ini ke lingkup v4.

Ada satu hal lagi yang saya abaikan untuk ditanyakan - nama Majelis. Tampaknya saat ini nama majelis juga dimulai dengan Ploeh. Jika kita menghapus awalan namespace, masuk akal untuk mengganti nama rakitan juga (misalnya dari Phoeh.AutoFixture.dll menjadi AutoFixture.dll ). Saya percaya bahwa NuGet akan menangani perubahan ini dengan anggun. Satu-satunya hal yang dapat kami khawatirkan adalah bahwa ini akan menjadi identitas perakitan baru dan tidak mungkin untuk melakukan pengalihan perakitan dari v3 ke v4.

Apa pendapat Anda tentang @moodmosaic , @adamchester dan @ecampidoglio ini - apakah Anda keberatan dengan

Setelah ruang nama diganti namanya di v4, pengalihan pengikatan perakitan ke v4 tidak akan ada artinya. Untuk alasan ini, dan agar konsisten, saya pikir masuk akal untuk mengganti nama rakitan menjadi AutoFixture(.*).

Poin bagus, saya melewatkan itu. Memang, semua jenis nama lengkap akan berbeda, jadi pengalihan tidak masuk akal. Kecuali @adamchester dan @ecampidoglio memiliki masalah lain - mari kita ganti nama juga.

Selesai! Ruang nama "Ploeh" dan awalan nama rakitan akan dihapus dari v4, sehingga akan dimulai dengan "Perbaikan Otomatis". Perubahan ini memungkinkan untuk mencerminkan kepemilikan yang diperbarui karena sekarang produk sedang dikembangkan oleh tim AutoFixture saja.

Ingatlah bahwa ini mematahkan garis kontinuitas sejauh menyangkut perakitan. Yaitu, paket baru tidak akan berisi versi rakitan baru. Sebaliknya, majelis sebelumnya akan dihapus, dan diganti dengan majelis yang sama sekali baru, dengan identitas baru. Ini berarti bahwa hal-hal seperti pengalihan pengikatan tidak dapat dibuat untuk bekerja antara rakitan yang terdapat dalam paket 3.x dan rakitan yang terdapat dalam 4.x.

Mungkin ini bukan masalah, tapi saya pikir ini layak untuk ditunjukkan.

BTW - sudahkah Anda memeriksa perilaku NuGet ketika paket ditingkatkan? Untuk proyek gaya SDK, saya kira semuanya akan berfungsi dengan baik, karena proyek hanya berisi elemen <PackageReference> yang menunjuk ke paket daripada rakitan. Tetapi dengan csproj gaya lama, mungkin perlu memverifikasi bahwa NuGet membuat perubahan yang diinginkan pada referensi Majelis, dari satu Majelis ke Majelis lainnya.

@adamralph Terima kasih atas perhatian Anda!

Ini berarti bahwa hal-hal seperti pengalihan pengikatan tidak dapat dibuat untuk bekerja antara rakitan yang terdapat dalam paket 3.x dan rakitan yang terdapat dalam 4.x.

Ya, saya tahu itu. Namun, kami telah mengubah namespace default, yang berarti kami mengubah identitas untuk semua jenis di dalam majelis. Dalam pengalihan pengikatan perakitan ringan ini tidak akan masuk akal karena kode tidak akan berfungsi dalam hal apa pun tanpa kompilasi ulang dan perbaikan impor. Oleh karena itu, saya yakin kita baik-baik saja dengan itu. Ini adalah perubahan besar, tetapi itu akan terjadi hanya untuk satu kali.

BTW - sudahkah Anda memeriksa perilaku NuGet ketika paket ditingkatkan?

Ya, saya sudah mengujinya dan berfungsi dengan baik. Satu-satunya hal yang perlu Anda lakukan adalah menjalankan penggantian teks untuk memperbaiki using Ploeh.AutoFixture menjadi using AutoFixture . Setelah proyek itu berhasil dikompilasi dan tes berjalan dengan sukses.

Satu-satunya hal yang perlu Anda lakukan adalah menjalankan penggantian teks untuk memperbaiki penggunaan Ploeh.AutoFixture menjadi menggunakan AutoFixture. Setelah itu proyek berhasil dikompilasi dan uji coba berhasil.

Iya benar sekali.

Apakah halaman ini membantu?
0 / 5 - 0 peringkat