Aggressive Namespace Polution

Aug 2, 2011 at 7:45 AM


PGK.Extensions is nice.

However, there is no enclosing namespace for the PGK.Extensions library.

So, as soon as you reference PGK.Extensions.dll, all types are now extended with extensions.

In some ways it pollutes VS IntelliSense with too many extension methods on all types, across all namespaces - this sometimes gets in the way of programming when exploring other types' real APIs.

I'd only like to use PGK.Extensions only in .CS files that I need (by adding "using PGK.Extensions" namespace).

There is no way to turn off PGK.Extensions when I don't want to use them in some CS files.

Aug 3, 2011 at 6:18 AM


Yes, this is a bit aggressive if you like it to call that way ;-) However we decided to do without a namespace long time ago and it would be hard to change that. So actually I can't see this happen as long as not most of the users ask for it.



Aug 10, 2011 at 5:22 AM

I agree with bchavez.
I think the namespace polution can be, or not, a problem. 
When the extension method is inherently to common programing problems, it`s fine to have it on System namespace, but if it's specific, it can be painful.

I think many method are very handy, I found, almost everything very compelling, but I disagree with some methods:

  • Extensions method in Object type is a bad idea, always!
  • Fooling the type system is kind of evil (Array.IsNullOrEmpty)
  • Boolean Opposed Method seems to be redundant: ValueType.IsNotEmpty and ValueType.IsEmpty, is even easier to write "!variable.IsEmpty"
  • In fact, it's not even common methods with "Not" in name: String.IsNotEmptyOrWhiteSpace
  • IEnumerable<T>.IgnoreNulls is easy to reproduce


But keep up the good work, you should, only, invest hard in test cases/unit testing.
I`d recommend the following book:
It has very useful tips, including Extension Methods guideline.



Aug 16, 2011 at 7:36 PM
Edited Aug 16, 2011 at 7:37 PM

While I appreciate this library I have to agree that I'm not a fan of the extensions residing in the global namespace either. I prefer to be explicit as to which extensions I choose to use in a given code file.

It's a fairly simple thing to download the source and change it yourself, however, especially if you have a tool like ReSharper handy... It literally takes minutes to fix unless you have to do the changes by hand. Even then it is still a pretty straightforward process.

Aug 20, 2011 at 6:39 PM
Edited Aug 20, 2011 at 6:50 PM

Hi Patrick,

Actually, it is not hard to change if you have ReSharper.

I downloaded the source code and moved all extensions into the PGK.Extensions namespace; then recompiled.

This way, if I want PGK extensions, I enable it, per source code file, by adding the "using PGK.Extensions".

The argument for residing in the global namespace can go both ways... however, your decision is forcing developers down a global namespace extension path that cannot be easily reversed or configured without having to recompile from source.

In my opinion, I think it would be best to release 2 dlls. This way, you can give developers a choice: global namespace, or extensions wrapped in "PGK.Extensions" namespace.


At least you can will give developers a path to continue following standard extension method guidelines.

You could have precompiler options:

#ifdef STRICT
namespace PGK.Extensions
{ //extension methods here... etc.

It is very frustrating using InteliSense with a polluted namespace -- of which is applied to the entire project on all objects.

What do you think about having 2 release DLLs?

Aug 21, 2011 at 11:13 AM

Hi there!

I'm absolutely open to have two versions of the extensions. Are you willing to impement the required changes?


Oct 12, 2011 at 1:51 AM

I'm curious... did this go anywhere?  I too would be interested in having this option.


-- Matthew

Oct 12, 2011 at 2:24 PM

Nope. There was not yet any feedback yet. Anybody is welcome to go ahead and set this up :-)

Nov 8, 2011 at 3:45 PM

I added a small patch that attempts to alleviate this issue. The main pollution comes from Object extensions. So those (and Constructor) extensions are placed into PGK.Extensions namespace like suggested above.

There're two separate builds. Normal and Strict.

If you have suggestions on how, what to improve I'll be happy to work on this issue a little bit more.

Feb 1, 2012 at 7:22 PM

This is awesome. Thanks so much for pushing a patch. I came back to check if there was any progress made on the issue. I hope Patrick will consider your patch.

I like your conservative approach with Object.