Autofixture: Liberação de namespace

Você poderia, por favor, explicar?

Eu diria que seria melhor com apenas using AutoFixture; que using Ploeh.AutoFixture;

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

Você poderia, por favor, explicar?

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/AutoFixture/AutoFixture/issues/538#issuecomment -191973353
.

Parece que a parte de Ploeh é um resquício de quando isso era pessoal
projeto de hobby, ou uma mera prova de conceito, ou experimento ... Não é
mais.

Quando o projeto ganha um pouco mais de tração (o que parece provável de acontecer, como
o mundo .NET está cada vez mais atraído pela DI), pode ser benéfico para
até mesmo mover o projeto para pertencer a alguma fundação AutoFixture.

Mas esse é um outro problema, é claro.

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

Eu diria que seria melhor com apenas using AutoFixture; que using Ploeh.AutoFixture;

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

Você poderia, por favor, explicar?

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/AutoFixture/AutoFixture/issues/538#issuecomment -191973353
.

Por favor, corrija-me se houver uma motivação técnica para esta sugestão, mas se eu entendi isso corretamente, é principalmente sobre percepção.

É correto adicionar a parte _Ploeh_ à maior parte do código que publico. O AutoFixture realmente começou como um projeto pessoal.

Alterar todos os namespaces no AutoFixture seria uma mudança importante, então não é algo que possamos fazer no AutoFixture 3, mas poderíamos considerá-lo para o AutoFixture 4.

O que as pessoas acham dessa sugestão? / cc @moodmosaic @ecampidoglio @adamchester

Sou apenas um usuário de autofixture e não vejo motivo para alterá-lo. Há muitas coisas úteis no blog Ploeh :)

Faz sentido do ponto de vista de um novo usuário, mas também não é um problema para ser honesto. A importação de namespaces geralmente é feita automaticamente por seu IDE de qualquer maneira.

Alias ​​de suas importações!

Não vejo nada de errado em _Ploeh_ ser parte do namespace.

Afinal, quando vejo _Ploeh_, sei que se trata de algo bom e de ótima qualidade.

Eu manteria como _Ploeh.AutoFixture_.

Acho que está tudo bem, a "marca" pública é AutoFixture ... realmente não importa quais são os namespaces.

Não é o mesmo com Json.NET ? namespaces começando com Newtonsoft.Json ...

Para referência: Solicitei comentários via Twitter: https://twitter.com/ploeh/status/705721775011848192

(Pode haver algumas respostas lá que não aparecem aqui.)

Não vejo nenhuma razão _de modo algum_ para alterar o namespace. Como @moodmosaic apontou , o nome _Ploeh_ está associado a qualidade e habilidade, então, em termos de percepção, faz muito sentido mantê-lo.

Além disso, não acho que haja nada de errado em permitir que a história do projeto seja exibida no namespace; é uma homenagem às raízes do projeto e ao autor que concebeu a ideia original.

Eu concordo com @ecampidoglio. Em uma nota relacionada, o que significa _ploeh_?

Também estou tendo um problema com o namespace do Json.NET como Newtonsoft! (: +1: @tsimbalar por me lembrar ...)

@ecampidoglio , meu ponto é que o projeto em si atingiu o ponto de utilidade _and_ habilidade que o ato de assinar o namespace se torna supérfluo. O que é a AutoFixtura torna isso desnecessário.

@ploeh : "våga" mergulhe!

Acho que não é um problema. Mas o OP pode bifurcar o projeto e remover o prefixo ofensivo. Em seguida, deixe os usuários decidirem o que preferem.

Sim; apenas se o próprio Ploeh decidisse removê-lo, você aceitaria
faça isso. Não é como se houvesse algum outro motivo para mantê-lo além de
alinhe-se com sua opinião (potencial) para fazer o mesmo.

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

Acho que não é um problema. Mas o OP pode bifurcar o projeto e remover o
prefixo ofensivo. Em seguida, deixe os usuários decidirem o que preferem.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/AutoFixture/AutoFixture/issues/538#issuecomment -192362828
.

Ok, essa última observação foi um pouco troll. Vou reformular: será que Ploeh pensa que chegou a hora?

Talvez a maioria dos usuários de autofixtura não se importe com isso?

Prefiro manter o namespace como está.

Eu iria deixar isso. Contribui para a 'singularidade' da nomenclatura. Alguém no futuro ainda pode criar Foo.AutoFixture, ou MS pode criar System.AutoFixture :)

Obrigado a todos por seus comentários!

Agora que esta discussão diminuiu, contei os 'votos' daqui e o tweet , e descobri que 2 pessoas são a favor desta sugestão, enquanto 10 pessoas gostariam de manter o namespace como está atualmente. Além disso, alguns comentários não indicam nenhuma preferência particular, então não os incluí em minha contagem.

No entanto, votarei para manter o namespace como está, então, na verdade, são 11 votos contra essa sugestão.

O motivo mais importante é que não acho a vantagem de fazer a mudança maior do que o custo.

A vantagem de fazer a mudança é, até onde sei, mínima. Eu entendo o argumento sobre percepção e não o discuto. É, no entanto, totalmente subjetivo. Por exemplo, sou um usuário encantado da biblioteca Unquote e não me incomoda nem um pouco que tenha que importar a biblioteca Swensen.Unquote .

O custo da mudança também é mínimo. Significaria, no entanto, que todo o código do usuário seria quebrado. A correção para isso seria trivial: as pessoas simplesmente precisariam deletar Ploeh. de suas diretivas de importação. (Tenho certeza de que alguma alma amigável até me dirá que o Resharper pode fazer isso automaticamente, mas agora estou apenas especulando.) Ainda assim, _é_ um inconveniente para os usuários, não importa o quão pequeno seja, por isso deve ser garantido.

Tanto a vantagem quanto a desvantagem de fazer a mudança são pequenas, portanto, não é uma decisão fácil. Nesses casos, costumo errar por excesso de cautela: não incomode os usuários sem motivo aparente. Ainda assim, é uma chamada tão próxima que solicitei feedback na tentativa de avaliar a opinião dos usuários sobre o assunto. Os resultados, embora estatisticamente insignificantes, não mudam minha opinião.

@ bjorn-ali-goransson, quero agradecer por iniciar esta discussão, que achei interessante. Fico feliz que alguém tenha a coragem de desafiar o status quo; você deve continuar fazendo isso.

Mesmo que minha decisão não aconteça como você gostaria, espero que ache que a deliberar com justiça.

@ploeh - Eu só queria ter um momento especial para parabenizá-lo pela abordagem colaborativa que você assumiu.

Não se surpreenda se eu enviar pessoas a este tíquete para ajudar a entender como o discurso no desenvolvimento de software deve ser conduzido. Sua técnica tem sido exatamente minha filosofia na discussão de questões técnicas.