Namespace liberation

[bjorn-ali-goransson]

How about liberating the namespace from the Ploeh?

[moodmosaic]

Could you please elaborate?

[bjorn-ali-goransson]

I'd say it would be nicer with just using AutoFixture; than using Ploeh.AutoFixture;

2016-03-03 22:34 GMT+01:00 Nikos Baxevanis notifications@github.com:

Could you please elaborate?

—
Reply to this email directly or view it on GitHub
#538 (comment)
.

[bjorn-ali-goransson]

It seems like the Ploeh part is a remnant from when this was a personal
hobby project, or a mere proof of concept, or experiment... It's not
anymore.

When the project gains some more traction (which seems likely to happen, as
the .NET world is drawn increasingly towards DI), it could be beneficial to
even move the project to being owned by some AutoFixture foundation.

But that's a whole nother issue, of course.

2016-03-03 22:37 GMT+01:00 Björn Göransson bjorn.a.goransson@gmail.com:

I'd say it would be nicer with just using AutoFixture; than using Ploeh.AutoFixture;

2016-03-03 22:34 GMT+01:00 Nikos Baxevanis notifications@github.com:

Could you please elaborate?

—
Reply to this email directly or view it on GitHub
#538 (comment)
.

[ploeh]

Please correct me if there's a technical motivation for this suggestion, but if I understand this correctly, it's mostly about perception.

It's correct that I add the Ploeh part to most of the code I publish. AutoFixture did indeed start out as a personal project.

Changing all the namespaces in AutoFixture would be a breaking change, so it's not something we can do in AutoFixture 3, but we could consider it for AutoFixture 4.

What do people think about this suggestion? /cc @moodmosaic @ecampidoglio @adamchester

[abenedykt]

Im just a user of autofixture and see no point to change it. Theres lots of useful stuff on Ploeh blog :)

[ErikSchierboom]

It kinda makes sense from a new user's standpoint, but it's also not really an issue to be honest. Importing namespaces is usually done automatically by your IDE anyway.

[atrauzzi]

Alias your imports!

[moodmosaic]

I don't see something wrong with Ploeh being part of the namespace.

After all, when I see Ploeh I know it's about something good, and of fine quality.

I'd keep it as Ploeh.AutoFixture.

[tsimbalar]

I think it's fine, the public "brand" is AutoFixture ... it doesn't really matter what the namespaces are.

Isn't it the same with Json.NET ? namespaces starting with Newtonsoft.Json ...

[ploeh]

For reference: I solicited comments via Twitter: https://twitter.com/ploeh/status/705721775011848192

(There may be some responses there that don't appear here.)

[ecampidoglio]

I don't see any reason at all to change the namespace. As @moodmosaic pointed out, the Ploeh name is associated with quality and craftsmanship so, perception-wise, it makes a lot of sense to keep it.

Also, I don't think there is anything wrong in letting the history of the project show in the namespace; it's an homage to the project's roots and to the author who conceived the original idea.

[dcastro]

I agree with @ecampidoglio. On a related note, what does ploeh mean?

[bjorn-ali-goransson]

I'm also having an issue with Json.NET being namespaced as Newtonsoft! ( 👍 @tsimbalar for reminding me... )

@ecampidoglio , my point is that the project in itself has reached the point of usefulness and craftmanship that the act of signing the namespace becomes superfluos. The thing that is AutoFixture makes that unnecessary.

@ploeh : "våga" take the plunge!

[sapiens]

I think it's a non issue. But the OP can fork the project and remove the offending prefix. Then let the users decide what they prefer.

[bjorn-ali-goransson]

Yes; only if Ploeh himself would choose to remove it, you would accept to
do so. It's not like there is some other reason to keep it other than to
align oneself with his (potential) opinion to do the same.

2016-03-04 18:13 GMT+01:00 Mike Mogosanu notifications@github.com:

I think it's a non issue. But the OP can fork the project and remove the
offending prefix. Then let the users decide what they prefer.

—
Reply to this email directly or view it on GitHub
#538 (comment)
.

[bjorn-ali-goransson]

Okay, that last remark was a bit too troll-y. I'll rephrase: Maybe Ploeh thinks that the time has come?

[sapiens]

Maybe most of the users of autofixture don't care about that?

[adamchester]

I prefer keeping the namespace as it is.

[gmaresca]

I would leave it. It contributes to the 'uniqueness' of the naming. Somebody in the future may still create Foo.AutoFixture, or MS can create System.AutoFixture :)

[ploeh]

Thank you, all, for your feedback!

Now that this discussion has abated, I've counted the 'votes' from here and the tweet, and find that 2 people are in favour of this suggestion, whereas 10 people would like to keep the namespace as it currently is. Additionally, a few comments indicate no particular preference, so I've not included them in my tally.

I will, however, cast my vote for keeping the namespace as is, though, so that's actually 11 votes against this suggestion.

The most important reason is that I don't find the advantage of making the change greater than the cost.

The advantage of making the change is, as far as I can tell, minimal. I understand the argument about perception, and I don't dispute it. It is, however, entirely subjective. As an example, I'm a delighted user of the Unquote library, and it bothers me not the slightest that I have to import the Swensen.Unquote library.

The cost of the change is minimal as well. It would mean, however, that all user code would break. The fix for that would be trivial: people would simply need to delete Ploeh. from their import directives. (I'm sure some friendly soul will even tell me that Resharper can do this automatically, but now I'm just speculating.) Still, it is an inconvenience to users, no matter how small, so it must be warranted.

Both the advantage and disadvantage in making the change are small, so it's no easy decision. In such cases, I tend to err on the side of caution: don't inconvenience users for no apparent reason. Still, it's a close enough call that I solicited feedback in an attempt to gauge users' views on the matter. The results, although statistically insignificant, don't change my opinion.

@bjorn-ali-goransson, I want to thank you for initiating this discussion, which I found worthwhile. I'm happy that someone has the courage to challenge the status quo; you should keep doing that.

Even though my decision doesn't go the way you'd like, I hope you find that I've given it fair deliberation.

[atrauzzi]

@ploeh - I just wanted to take a special moment to applaud you for the collaborative approach you took on this.

Don't be surprised if I send people to this ticket to help understand how discourse in software development should be conducted. Your technique has been exactly my philosophy on discussion of technical matters.