Autofixture: Libération de l'espace de noms

Pourriez-vous s'il vous plaît élaborer?

Je dirais que ce serait mieux avec seulement using AutoFixture; qu'avec using Ploeh.AutoFixture;

03-03-2016 22:34 GMT":" Nikos Baxevanis [email protected] :

Pourriez-vous s'il vous plaît élaborer?

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/AutoFixture/AutoFixture/issues/538#issuecomment -191973353
.

Il semble que la partie Ploeh soit un vestige de l'époque où il s'agissait d'un
projet de passe-temps, ou une simple preuve de concept, ou une expérience... Ce n'est pas
plus.

Lorsque le projet gagnera en popularité (ce qui semble probable, car
le monde .NET est de plus en plus attiré par DI), il pourrait être bénéfique de
même déplacer le projet pour qu'il appartienne à une fondation AutoFixture.

Mais c'est un tout autre problème, bien sûr.

03/03/2016 22:37 GMT":" Björn Göransson bjorn.a. [email protected] :

Je dirais que ce serait mieux avec seulement using AutoFixture; qu'avec using Ploeh.AutoFixture;

03-03-2016 22:34 GMT":" Nikos Baxevanis [email protected] :

Pourriez-vous s'il vous plaît élaborer?

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/AutoFixture/AutoFixture/issues/538#issuecomment -191973353
.

Veuillez me corriger s'il y a une motivation technique pour cette suggestion, mais si je comprends bien, c'est surtout une question de perception.

Il est vrai que j'ajoute la partie _Ploeh_ à la plupart du code que je publie. AutoFixture a en effet commencé comme un projet personnel.

Changer tous les espaces de noms dans AutoFixture serait un changement décisif, donc ce n'est pas quelque chose que nous pouvons faire dans AutoFixture 3, mais nous pourrions l'envisager pour AutoFixture 4.

Que pensent les gens de cette suggestion ? /cc @moodmosaic @ecampidoglio @adamchester

Je suis juste un utilisateur d'autofixation et je ne vois aucun intérêt à le changer. Il y a plein de trucs utiles sur le blog de Ploeh :)

Cela a un peu de sens du point de vue d'un nouvel utilisateur, mais ce n'est pas non plus vraiment un problème pour être honnête. L'importation d'espaces de noms est généralement effectuée automatiquement par votre IDE de toute façon.

Aliasez vos importations !

Je ne vois rien de mal à ce que _Ploeh_ fasse partie de l'espace de noms.

Après tout, quand je vois _Ploeh_, je sais qu'il s'agit de quelque chose de bien et de belle qualité.

Je le garderais comme _Ploeh.AutoFixture_.

Je pense que ça va, la "marque" publique est AutoFixture ... peu importe les espaces de noms.

N'en est-il pas de même avec

Pour référence : j'ai sollicité des commentaires via Twitter : https://twitter.com/ploeh/status/705721775011848192

(Il peut y avoir des réponses qui n'apparaissent pas ici.)

Je ne vois aucune raison _du tout_ de changer l'espace de noms. Comme @moodmosaic l'a souligné , le nom _Ploeh_ est associé à la qualité et à l'artisanat, donc, du point de vue de la perception, il est tout à fait logique de le conserver.

De plus, je ne pense pas qu'il y ait quoi que ce soit de mal à laisser l'historique du projet s'afficher dans l'espace de noms ; c'est un hommage aux racines du projet et à l'auteur qui a conçu l'idée originale.

Je suis d'accord avec @ecampidoglio. Sur une note connexe, que signifie _ploeh_ ?

J'ai également un problème avec l'espace de noms de Json.NET en tant que Newtonsoft ! ( :+1: @tsimbalar pour me l'avoir rappelé... )

@ecampidoglio , mon point est que le projet en lui-même a atteint le point d'utilité _et_ de savoir-faire que l'acte de signer l'espace de noms devient superflu. La chose qui est AutoFixture rend cela inutile.

@ploeh : "våga" saute le pas !

Je pense que ce n'est pas un problème. Mais l'OP peut bifurquer le projet et supprimer le préfixe incriminé. Laissez ensuite les utilisateurs décider ce qu'ils préfèrent.

Oui; seulement si Ploeh lui-même choisissait de le supprimer, vous accepteriez de
le faire. Ce n'est pas comme s'il y avait une autre raison de le garder autre que de
s'aligner sur son opinion (potentielle) pour faire de même.

04/03/2016 18:13 GMT":" Mike Mogosanu [email protected] :

Je pense que ce n'est pas un problème. Mais l'OP peut bifurquer le projet et supprimer le
préfixe incriminé. Laissez ensuite les utilisateurs décider ce qu'ils préfèrent.

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/AutoFixture/AutoFixture/issues/538#issuecomment -192362828
.

D'accord, cette dernière remarque était un peu trop troll-y. Je vais reformuler : peut-être que Ploeh pense que le moment est venu ?

Peut-être que la plupart des utilisateurs d'autofixation ne s'en soucient pas ?

Je préfère garder l'espace de noms tel qu'il est.

Je le laisserais. Il contribue à l'« unicité » de la dénomination. Quelqu'un dans le futur peut encore créer Foo.AutoFixture, ou MS peut créer System.AutoFixture :)

Merci à tous pour vos retours !

Maintenant que cette discussion s'est apaisée, j'ai compté les "votes" d'ici et le tweet , et constate que 2 personnes sont en faveur de cette suggestion, alors que 10 personnes aimeraient garder l'espace de noms tel qu'il est actuellement. De plus, quelques commentaires n'indiquent aucune préférence particulière, je ne les ai donc pas inclus dans mon décompte.

Cependant, je voterai pour le maintien de l'espace de noms tel quel, ce qui représente en fait 11 votes contre cette suggestion.

La raison la plus importante est que je ne trouve pas l'avantage de rendre le changement supérieur au coût.

L'avantage de faire le changement est, pour autant que je sache, minime. Je comprends l'argument sur la perception, et je ne le conteste pas. Mais c'est tout à fait subjectif. Par exemple, je suis un utilisateur ravi de la bibliothèque Unquote , et cela ne me dérange pas le moins du monde que je Swensen.Unquote .

Le coût du changement est également minime. Cela signifierait, cependant, que tout le code utilisateur se briserait. Le correctif serait trivial : les utilisateurs auraient simplement besoin de supprimer Ploeh. de leurs directives d'importation. (Je suis sûr qu'une âme amicale me dira même que Resharper peut le faire automatiquement, mais maintenant je ne fais que spéculer.) Pourtant, c'est un inconvénient pour les utilisateurs, aussi petit soit-il, donc cela doit être justifié.

L'avantage et l'inconvénient de faire le changement sont faibles, ce n'est donc pas une décision facile. Dans de tels cas, j'ai tendance à pécher par excès de prudence : ne dérangez pas les utilisateurs sans raison apparente. Pourtant, c'est un appel suffisamment proche pour que j'aie sollicité des commentaires dans le but d'évaluer le point de vue des utilisateurs sur la question. Les résultats, bien que statistiquement insignifiants, ne changent pas mon opinion.

@bjorn-ali-goransson, je tiens à vous remercier d'avoir initié cette discussion, que j'ai trouvée intéressante. Je suis heureux que quelqu'un ait le courage de défier le statu quo ; tu devrais continuer à faire ça.

Même si ma décision ne se déroule pas comme vous le souhaiteriez, j'espère que vous trouverez que je l'ai délibérément réfléchie.

@ploeh - Je voulais juste prendre un moment spécial pour vous féliciter pour l'approche collaborative que vous avez adoptée à ce sujet.

Ne soyez pas surpris si j'envoie des personnes à ce ticket pour les aider à comprendre comment le discours sur le développement de logiciels doit être mené. Votre technique a été exactement ma philosophie sur la discussion des questions techniques.