Autofixture: 命名空间解放

你能详细说明一下吗？

我会说using AutoFixture;比using Ploeh.AutoFixture;更好

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

你能详细说明一下吗？

—
直接回复此邮件或在 GitHub 上查看
https://github.com/AutoFixture/AutoFixture/issues/538#issuecomment -191973353
.

似乎 Ploeh 部分是个人的残余
爱好项目，或者仅仅是概念的证明，或者实验......它不是
了。

当项目获得更多吸引力时（这似乎很可能发生，因为
.NET 世界越来越倾向于 DI），这可能有益于
甚至将项目转移到某个 AutoFixture 基金会所有。

但这当然是另一个问题。

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

我会说using AutoFixture;比using Ploeh.AutoFixture;更好

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

你能详细说明一下吗？

—
直接回复此邮件或在 GitHub 上查看
https://github.com/AutoFixture/AutoFixture/issues/538#issuecomment -191973353
.

如果此建议有技术动机，请纠正我，但如果我理解正确，则主要是关于感知。

我将 _Ploeh_ 部分添加到我发布的大部分代码中是正确的。 AutoFixture 确实是从个人项目开始的。

更改 AutoFixture 中的所有命名空间将是一个重大更改，因此我们在 AutoFixture 3 中无法做到这一点，但我们可以考虑将其用于 AutoFixture 4。

人们如何看待这个建议？ /cc @moodmosaic @ecampidoglio @adamchester

我只是一个 autofixture 的用户，没有必要改变它。 Ploeh 博客上有很多有用的东西 :)

从新用户的角度来看，这有点道理，但老实说，这也不是真正的问题。 无论如何，导入命名空间通常由您的 IDE 自动完成。

别名您的进口！

我不认为 _Ploeh_ 作为命名空间的一部分有什么问题。

毕竟，当我看到 _Ploeh_ 时，我知道它是关于好东西，而且质量上乘。

我将其保留为 _Ploeh.AutoFixture_。

我认为这很好，公共“品牌”是AutoFixture ......命名空间是什么并不重要。

与Json.NET不一样吗？ 以 Newtonsoft.Json 开头的命名空间...

供参考：我通过推特征求意见： https :

（那里可能有一些反应没有出现在这里。）

我看不出有任何理由 _at all_ 更改命名空间。 正如@moodmosaic指出的那样，_Ploeh_ 名称与质量和工艺有关，因此，从感知角度来看，保留它很有意义。

另外，我认为让项目的历史显示在命名空间中没有任何问题； 这是对项目的根源和构思最初想法的作者的致敬。

我同意@ecampidoglio。 在相关说明中，_ploeh_ 是什么意思？

我也遇到了 Json.NET 命名空间为 Newtonsoft 的问题！ （：+1： @tsimbalar提醒我...）

@ecampidoglio ，我的观点是，项目本身已经达到了有用的点_和_手艺，签署命名空间的行为变得多余。 AutoFixture 使这变得不必要。

@ploeh ：“våga”冒险一试！

我认为这不是问题。 但是 OP 可以 fork 项目并删除有问题的前缀。 然后让用户决定他们喜欢什么。

是的; 只有当 Ploeh 自己选择删除它时，你才会接受
这样做。 除了为了保留它之外，并没有其他理由保留它
使自己与他的（潜在）意见保持一致以做同样的事情。

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

我认为这不是问题。 但是 OP 可以 fork 项目并删除
冒犯前缀。 然后让用户决定他们喜欢什么。

—
直接回复此邮件或在 GitHub 上查看
https://github.com/AutoFixture/AutoFixture/issues/538#issuecomment -192362828
.

好吧，最后一句话有点太巨魔了。 我会改写：也许 Ploeh 认为时机已到？

也许大多数 autofixture 的用户并不关心这一点？

我更喜欢保持命名空间的原样。

我会离开它。 它有助于命名的“独特性”。 将来有人可能仍会创建 Foo.AutoFixture，或者 MS 可以创建 System.AutoFixture :)

谢谢大家的反馈！

现在讨论已经结束，我计算了这里和推文中的“投票”，发现有 2 人支持这个建议，而 10 人希望保留当前的命名空间。 此外，一些评论表明没有特别偏好，所以我没有将它们包括在我的统计中。

但是，我将投票支持保持命名空间不变，因此实际上有 11 票反对该建议。

最重要的原因是我没有发现使更改大于成本的优势。

据我所知，做出改变的好处微乎其微。 我理解关于感知的争论，我不反对它。 然而，这完全是主观的。 例如，我很高兴使用Unquote库，我对导入Swensen.Unquote库一点也不感到困扰。

更改的成本也是最低的。 然而，这意味着所有用户代码都会被破坏。 解决这个问题很简单：人们只需要从他们的导入指令中删除Ploeh. 。 （我敢肯定，一些友好的人甚至会告诉我 Resharper 可以自动执行此操作，但现在我只是在猜测。） 尽管如此，它_is_ 给用户带来了不便，无论多么小，所以必须有保证。

做出改变的好处和坏处都很小，所以这不是一个容易的决定。 在这种情况下，我倾向于谨慎行事：不要无缘无故地给用户带来不便。 尽管如此，这是一个足够接近的电话，我征求了反馈意见，试图衡量用户对此事的看法。 结果虽然在统计上微不足道，但并没有改变我的看法。

@bjorn-ali-goransson，我要感谢您发起这次讨论，我认为这是值得的。 我很高兴有人有勇气挑战现状； 你应该继续这样做。

即使我的决定没有按照您的意愿进行，但我希望您会发现我已经进行了公平的考虑。

@ploeh - 我只是想花一个特别的时间来为你在这件事上采取的协作方法鼓掌。

如果我派人到这张票来帮助理解软件开发中的讨论应该如何进行，请不要感到惊讶。 你的技术正是我讨论技术问题的哲学。