What is meant via the phase "Does not Pollute the Name space"?

[StrawHat]

Hello,

I am not familiar with the term “does not pollute the Names space”. Can you please explain or provide some resource?

Thanks in advance

[bixarrio]

Namespaces are intended to keep things organised and separated. ‘Polluting the namespace’ really just means putting something in a namespace that doesn’t belong there.

For instance, if we have a namespace called MyGame.Combat, there should not be anything related to the inventory in there, i.e. we don’t want to put the InventoryItem in the MyGame.Combat namespace.

I’m sure @Brian_Trotter can give far more comprehensive examples and reasons here

[Brian_Trotter]

Namespace pollution is something that means more in C++ (where it can actually lead to serious memory/garbage collection issues) than it does in C#, but it’s still important to keep your project organized into namespaces, at least when it gets large enough. (Most of the beginner projects in our 3d and 2d course aren’t really big enough to concern ourselves with namespaces, but good organization becomes absolutely vital once you get a project like the RPG series.

Ideally, your namespace should contain classes that are all about maintaining one related group of tasks, for example: You might have a namespace combat which contains logic for fighting, and weapon definitions, a ‘namespace movement’ which contains logic for movement, etc.

Also ideal within a namespace is a principle that there are as few as possible public entry points into the namespace functions and as much logic as possible is kept private, or internal to the namespace. Unfortunately, the keyword that Microsoft came up with for keeping things internal means that it’s internal to the assembly and not internal the namespace.

This means that an ideal solution would be combining namespaces with assemblies… This opens up the internal scope definition, meaning that a class can have information only accessible to other classes within the namespace, but not outside of the namespace.

Even without Assembly definitions, if you stick to your guns, and reference as little as possible in other classes and namespace – just what you need and follow the Law of Demeter, you can avoid some of the pitfalls of namespace pollution.

Now for applying the namespace pollution issue to Singletons… This is a larger problem for C++ than C# because of the way linking rules apply. It’s very easy for your Singleton to become more than a scoreboard or a link to the player. Let’s take a PlayerController singleton, for example:

Suppose you have a PlayerController class that is made into a Singleton, so you can keep moving the player around from scene to scene. It’s not as far fetched as it sounds, I can think of one project off the top of my head here at GameDev that uses exactly that model.

Now our PlayerController Singleton might be in a namespace Control, but it undoubtedly contains links and references to other namespaces

using UnityEngine;
using Movement;
using Combat;
using Vitals;

public namespace Control
{
    public class PlayerController : MonoBehaviour
    {
         public static PlayerController instance;
         private Mover mover; //from namespace Movement
         private Fighter fighter; //from namespace Fighter
         
         void Awake()
         {
               if(instance!=null)
               {      
                    destroy gameObject;
                    return;
                }
                else
                {
                      instance = this;
                      DontDestroyOnLoad(gameObject);
                 }
                 fighter = GetComponent<Fighter>();
                 mover = GetComponent<Mover>();
          }
     }
}

Now I’m not going to complete the class here, as it’s not neccessary for what I want to demonstrate. Often, we’ll get hold of the Player’s gameObject by calling

PlayerController.instance.gameObject;

This seems harmless enough, and all you would need to add to your usings clauses in whatever class you have is

using Control;

Here’s where it gets tricky. Suppose you’re only getting that reference to the player so that you can get an Inventory component off of the Player…

using Control;
using Inventories;

public class InventoryUI:MonoBehaviour
{
    Inventory inventory; //In namespace Inventories
    
     void Awake()
     {
          inventory = PlayerController.instance.GetComponent<Inventory>();
      }
}

This looks harmless enough, but in addition to linking to the Control class, linker also has to wade through the Combat and Movement namespaces when our class isn’t interested in either of these two classes.

It’s actually not a huge issue in C# because the linker should prune these references at compile time (though there is still that time to do that). In C++, it’s a bigger deal as the compiler will be reading the relevant includes each time you do this. The linker will likely prune them, but not before they’ve been read extra times.

This isn’t saying all Singletons are evil, but we need to be mindful of the things we’re doing that we think are saving time and code that could actually be creating more work for the compiler/linker, and we could be opening ourselves up for more unintended cross references.