Autofixture: Namensraumbefreiung

Könnten Sie bitte näher erläutern?

Ich würde sagen, es wäre schöner mit nur using AutoFixture; als mit using Ploeh.AutoFixture;

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

Könnten Sie bitte näher erläutern?

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/AutoFixture/AutoFixture/issues/538#issuecomment -191973353
.

Es scheint, als wäre der Ploeh-Teil ein Überbleibsel aus der Zeit, als dies ein persönlicher war
Hobbyprojekt, oder nur ein Proof of Concept, oder ein Experiment... Ist es nicht
nicht mehr.

Wenn das Projekt an Fahrt gewinnt (was wahrscheinlich passieren wird, da
die .NET-Welt wird zunehmend von DI angezogen), könnte es von Vorteil sein,
sogar das Projekt in den Besitz einer AutoFixture-Stiftung überführen.

Aber das ist natürlich ein ganz anderes Thema.

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

Ich würde sagen, es wäre schöner mit nur using AutoFixture; als mit using Ploeh.AutoFixture;

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

Könnten Sie bitte näher erläutern?

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/AutoFixture/AutoFixture/issues/538#issuecomment -191973353
.

Bitte korrigiert mich, wenn es eine technische Motivation für diesen Vorschlag gibt, aber wenn ich das richtig verstehe, geht es hauptsächlich um Wahrnehmung.

Es ist richtig, dass ich den _Ploeh_-Teil zum größten Teil des von mir veröffentlichten Codes hinzufüge. AutoFixture hat tatsächlich als persönliches Projekt begonnen.

Das Ändern aller Namespaces in AutoFixture wäre eine bahnbrechende Änderung, daher können wir dies in AutoFixture 3 nicht tun, aber wir könnten es für AutoFixture 4 in Betracht ziehen.

Was halten die Leute von diesem Vorschlag? /cc @moodmosaic @ecampidoglio @adamchester

Ich bin nur ein Benutzer von Autofixture und sehe keinen Sinn, es zu ändern. Es gibt viele nützliche Dinge auf dem Ploeh-Blog :)

Aus der Sicht eines neuen Benutzers macht es irgendwie Sinn, aber es ist auch nicht wirklich ein Problem, um ehrlich zu sein. Das Importieren von Namespaces wird normalerweise sowieso automatisch von Ihrer IDE durchgeführt.

Alias ​​Ihre Importe!

Ich sehe nichts falsch daran, dass _Ploeh_ Teil des Namensraums ist.

Immerhin, wenn ich _Ploeh_ sehe, weiß ich, dass es sich um etwas Gutes und von guter Qualität handelt.

Ich würde es als _Ploeh.AutoFixture_ behalten.

Ich denke, es ist in Ordnung, die öffentliche "Marke" ist AutoFixture ... es spielt keine Rolle, was die Namespaces sind.

Ist es bei Json.NET nicht

Als Referenz: Ich habe über Twitter um Kommentare gebeten: https://twitter.com/ploeh/status/705721775011848192

(Es kann dort einige Antworten geben, die hier nicht erscheinen.)

Ich sehe keinen Grund _überhaupt_ den Namensraum zu ändern. Wie @moodmosaic betonte, wird der Name _Ploeh_ mit Qualität und Handwerkskunst in Verbindung gebracht, daher ist es in Bezug auf die Wahrnehmung sehr sinnvoll, ihn beizubehalten.

Außerdem glaube ich nicht, dass es falsch ist, die Geschichte des Projekts im Namensraum anzeigen zu lassen; Es ist eine Hommage an die Wurzeln des Projekts und an den Autor, der die ursprüngliche Idee entwickelt hat.

Ich stimme @ecampidoglio zu. Was bedeutet in einem ähnlichen Zusammenhang _ploeh_?

Ich habe auch ein Problem damit, dass Json.NET als Newtonsoft benannt wird! ( :+1: @tsimbalar für die Erinnerung... )

@ecampidoglio , mein Punkt ist, dass das Projekt an sich den Punkt der Nützlichkeit _und_ Handwerkskunst erreicht hat, dass das Signieren des Namensraums überflüssig wird. Die Sache, die AutoFixture ist, macht das überflüssig.

@ploeh : "våga" nimm den Sprung!

Ich denke, es ist kein Thema. Aber das OP kann das Projekt verzweigen und das störende Präfix entfernen. Dann lassen Sie die Benutzer entscheiden, was sie bevorzugen.

Jawohl; nur wenn Ploeh selbst entscheiden würde, es zu entfernen, würdest du es akzeptieren
tun Sie dies. Es ist nicht so, dass es einen anderen Grund gibt, es zu behalten, als zu
sich an seiner (möglichen) Meinung ausrichten, um dasselbe zu tun.

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

Ich denke, es ist kein Thema. Aber das OP kann das Projekt abspalten und das entfernen
beleidigendes Präfix. Dann lassen Sie die Benutzer entscheiden, was sie bevorzugen.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/AutoFixture/AutoFixture/issues/538#issuecomment -192362828
.

Okay, diese letzte Bemerkung war ein bisschen zu trollig. Ich formuliere um: Vielleicht denkt Ploeh, dass die Zeit gekommen ist?

Vielleicht ist das den meisten Benutzern von Autofixture egal?

Ich ziehe es vor, den Namensraum so zu belassen, wie er ist.

Ich würde es lassen. Es trägt zur „Einzigartigkeit“ der Namensgebung bei. Jemand in der Zukunft kann immer noch Foo.AutoFixture erstellen, oder MS kann System.AutoFixture erstellen :)

Vielen Dank an alle für Ihr Feedback!

Nachdem diese Diskussion nun abgeklungen ist, habe ich die "Stimmen" von hier und dem Tweet gezählt und

Ich werde jedoch meine Stimme dafür abgeben, dass der Namespace so bleibt, wie er ist, das sind also tatsächlich 11 Stimmen gegen diesen Vorschlag.

Der wichtigste Grund ist, dass ich den Vorteil der Änderung nicht größer finde als die Kosten.

Der Vorteil der Änderung ist, soweit ich das beurteilen kann, minimal. Ich verstehe das Argument über die Wahrnehmung und bestreite es nicht. Es ist jedoch völlig subjektiv. Ich bin beispielsweise ein begeisterter Benutzer der Unquote- Bibliothek, und es stört mich nicht im Geringsten, dass ich die Swensen.Unquote Bibliothek importieren muss.

Auch die Kosten für den Wechsel sind minimal. Dies würde jedoch bedeuten, dass der gesamte Benutzercode brechen würde. Die Lösung dafür wäre trivial: Die Leute müssten einfach Ploeh. aus ihren Importanweisungen löschen. (Ich bin sicher, eine freundliche Seele wird mir sogar sagen, dass Resharper dies automatisch tun kann, aber jetzt spekuliere ich nur.) Trotzdem _ist_ es eine Unannehmlichkeit für Benutzer, egal wie klein sie auch sein mag, also muss sie gerechtfertigt sein.

Sowohl der Vor- als auch der Nachteil einer Änderung sind gering, sodass die Entscheidung nicht leicht fällt. In solchen Fällen tendiere ich dazu, auf Nummer sicher zu gehen: Belästigen Sie die Benutzer nicht ohne ersichtlichen Grund. Dennoch ist es nahe genug, dass ich um Feedback gebeten habe, um die Meinungen der Benutzer zu diesem Thema einzuschätzen. Die Ergebnisse, obwohl statistisch unbedeutend, ändern meine Meinung nicht.

@bjorn-ali-goransson, ich möchte Ihnen für die Initiierung dieser Diskussion danken, die ich als lohnenswert fand. Ich freue mich, dass jemand den Mut hat, den Status Quo in Frage zu stellen; das solltest du weiter machen.

Auch wenn meine Entscheidung nicht so verläuft, wie Sie es sich wünschen, hoffe ich, dass ich sie fair überlegt habe.

@ploeh - Ich wollte dir nur einen besonderen Moment nehmen, um dir für den kollaborativen Ansatz zu applaudieren, den du dabei verfolgt hast.

Seien Sie nicht überrascht, wenn ich Leute zu diesem Ticket schicke, um zu verstehen, wie der Diskurs in der Softwareentwicklung geführt werden sollte. Ihre Technik war genau meine Philosophie bei der Diskussion technischer Fragen.