New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Namespace liberation #538
Comments
Could you please elaborate? |
I'd say it would be nicer with just 2016-03-03 22:34 GMT+01:00 Nikos Baxevanis notifications@github.com:
|
It seems like the Ploeh part is a remnant from when this was a personal When the project gains some more traction (which seems likely to happen, as 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:
|
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! ( 👍 @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 2016-03-04 18:13 GMT+01:00 Mike Mogosanu notifications@github.com:
|
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 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 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. |
How about liberating the namespace from the
Ploeh
?The text was updated successfully, but these errors were encountered: