Autofixture: Namespace liberation

Created on 3 Mar 2016  ·  21Comments  ·  Source: AutoFixture/AutoFixture

How about liberating the namespace from the Ploeh?

question

Most helpful comment

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.

All 21 comments

Could you please elaborate?

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 [email protected]:

Could you please elaborate?


Reply to this email directly or view it on GitHub
https://github.com/AutoFixture/AutoFixture/issues/538#issuecomment-191973353
.

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.[email protected]:

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 [email protected]:

Could you please elaborate?


Reply to this email directly or view it on GitHub
https://github.com/AutoFixture/AutoFixture/issues/538#issuecomment-191973353
.

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

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

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.

Alias your imports!

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_.

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 ...

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

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

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.

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

I'm also having an issue with Json.NET being namespaced as Newtonsoft! ( :+1: @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!

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.

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 [email protected]:

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
https://github.com/AutoFixture/AutoFixture/issues/538#issuecomment-192362828
.

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

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

I prefer keeping the namespace as it is.

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 :)

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.

@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.

Was this page helpful?
0 / 5 - 0 ratings