Autofixture: Liberación del espacio de nombres

¿Podrías dar más detalles?

Yo diría que sería mejor con solo using AutoFixture; que using Ploeh.AutoFixture;

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

¿Podrías dar más detalles?

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/AutoFixture/AutoFixture/issues/538#issuecomment -191973353
.

Parece que la parte de Ploeh es un remanente de cuando esto era un asunto personal.
proyecto de pasatiempo, o una mera prueba de concepto, o experimento ... No es
ya no.

Cuando el proyecto gane algo más de tracción (lo que parece probable que suceda, como
el mundo .NET se inclina cada vez más hacia DI), podría ser beneficioso
incluso mover el proyecto para que sea propiedad de alguna fundación de AutoFixture.

Pero ese es otro tema, por supuesto.

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

Yo diría que sería mejor con solo using AutoFixture; que using Ploeh.AutoFixture;

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

¿Podrías dar más detalles?

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/AutoFixture/AutoFixture/issues/538#issuecomment -191973353
.

Corríjame si hay una motivación técnica para esta sugerencia, pero si la entiendo correctamente, se trata principalmente de percepción.

Es correcto que agregue la parte _Ploeh_ a la mayor parte del código que publico. De hecho, AutoFixture comenzó como un proyecto personal.

Cambiar todos los espacios de nombres en AutoFixture sería un cambio importante, por lo que no es algo que podamos hacer en AutoFixture 3, pero podríamos considerarlo para AutoFixture 4.

¿Qué piensa la gente sobre esta sugerencia? / cc @moodmosaic @ecampidoglio @adamchester

Soy solo un usuario de la autofijación y no veo ningún sentido para cambiarlo. Hay muchas cosas útiles en el blog de Ploeh :)

Tiene sentido desde el punto de vista de un nuevo usuario, pero tampoco es un problema para ser honesto. De todos modos, su IDE suele realizar la importación de espacios de nombres de forma automática.

¡Alias ​​tus importaciones!

No veo nada malo en que _Ploeh_ sea parte del espacio de nombres.

Después de todo, cuando veo _Ploeh_ sé que se trata de algo bueno y de buena calidad.

Lo mantendría como _Ploeh.AutoFixture_.

Creo que está bien, la "marca" pública es AutoFixture ... realmente no importa cuáles sean los espacios de nombres.

¿No es lo mismo con Json.NET ? espacios de nombres que comienzan con Newtonsoft.Json ...

Para referencia: solicité comentarios a través de Twitter: https://twitter.com/ploeh/status/705721775011848192

(Puede haber algunas respuestas allí que no aparecen aquí).

No veo ninguna razón _en absoluto_ para cambiar el espacio de nombres. Como señaló @moodmosaic , el nombre _Ploeh_ está asociado con la calidad y la artesanía, por lo que, en términos de percepción, tiene mucho sentido mantenerlo.

Además, no creo que haya nada de malo en dejar que la historia del proyecto se muestre en el espacio de nombres; es un homenaje a las raíces del proyecto y al autor que concibió la idea original.

Estoy de acuerdo con @ecampidoglio. En una nota relacionada, ¿qué significa _ploeh_?

¡También tengo un problema con Json.NET con un espacio de nombres como Newtonsoft! (: +1: @tsimbalar por recordarme ...)

@ecampidoglio , lo que quiero decir es que el proyecto en sí mismo ha alcanzado el punto de utilidad _y_ artesanía en el que el acto de firmar el espacio de nombres se vuelve superfluo. Lo que es AutoFixture lo hace innecesario.

@ploeh : "våga" ¡da el paso!

Creo que no es un problema. Pero el OP puede bifurcar el proyecto y eliminar el prefijo ofensivo. Luego, deje que los usuarios decidan lo que prefieren.

Sí; solo si el propio Ploeh decidiera eliminarlo, aceptaría
hazlo. No es como si hubiera alguna otra razón para conservarlo que no sea para
alinearse con su (potencial) opinión para hacer lo mismo.

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

Creo que no es un problema. Pero el OP puede bifurcar el proyecto y eliminar el
prefijo ofensivo. Luego, deje que los usuarios decidan lo que prefieren.

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/AutoFixture/AutoFixture/issues/538#issuecomment -192362828
.

De acuerdo, ese último comentario fue demasiado troll. Lo reformularé: ¿Quizás Ploeh piensa que ha llegado el momento?

¿Quizás a la mayoría de los usuarios de autofixture no les importa eso?

Prefiero mantener el espacio de nombres como está.

Lo dejaría. Contribuye a la "singularidad" del nombre. Alguien en el futuro aún puede crear Foo.AutoFixture, o MS puede crear System.AutoFixture :)

¡Gracias a todos por sus comentarios!

Ahora que esta discusión ha disminuido, he contado los 'votos' de aquí y el tweet , y descubrí que 2 personas están a favor de esta sugerencia, mientras que a 10 personas les gustaría mantener el espacio de nombres como está actualmente. Además, algunos comentarios no indican ninguna preferencia particular, por lo que no los he incluido en mi recuento.

Sin embargo, emitiré mi voto para mantener el espacio de nombres como está, por lo que en realidad son 11 votos en contra de esta sugerencia.

La razón más importante es que no encuentro la ventaja de hacer que el cambio sea mayor que el costo.

La ventaja de hacer el cambio es, que yo sepa, mínima. Entiendo el argumento sobre la percepción y no lo disputo. Sin embargo, es completamente subjetivo. Como ejemplo, soy un usuario encantado de la biblioteca Unquote , y no me molesta en lo más mínimo tener que importar la biblioteca Swensen.Unquote .

El costo del cambio también es mínimo. Sin embargo, significaría que todo el código de usuario se rompería. La solución sería trivial: las personas simplemente necesitarían eliminar Ploeh. de sus directivas de importación. (Estoy seguro de que algún alma amigable incluso me dirá que Resharper puede hacer esto automáticamente, pero ahora solo estoy especulando). Aún así, _es_ un inconveniente para los usuarios, no importa cuán pequeño sea, por lo que debe estar justificado.

Tanto la ventaja como la desventaja de realizar el cambio son pequeñas, por lo que no es una decisión fácil. En tales casos, tiendo a pecar de cauteloso: no molestes a los usuarios sin razón aparente. Aún así, es una llamada lo suficientemente cercana como para solicitar comentarios en un intento de evaluar las opiniones de los usuarios sobre el asunto. Los resultados, aunque estadísticamente insignificantes, no cambian mi opinión.

@ bjorn-ali-goransson, quiero agradecerles por iniciar esta discusión, que encontré valiosa. Me alegra que alguien tenga el coraje de desafiar el status quo; deberías seguir haciendo eso.

Aunque mi decisión no sale como usted quisiera, espero que descubra que la he deliberado de manera justa.

@ploeh - Solo quería tomarme un momento especial para aplaudirlo por el enfoque colaborativo que adoptó en esto.

No se sorprenda si envío personas a este ticket para ayudar a comprender cómo se debe conducir el discurso en el desarrollo de software. Su técnica ha sido exactamente mi filosofía en la discusión de asuntos técnicos.