What are the advantages of using namespaces in Delphi?

Question

From the 2009 version of Delphi (if I’m not mistaken) came the namespaces.
I would like to know, in a simple example if possible that illustrates a case of advantage, what would be the advantages of namespaces in Delphi?

Explaining a little about namespaces, on C# we could have three files containing the same namespace:

Filing cabinet Cs accounts.:

namespace Projeto.Forms {
    public class ContasForm : Form {
       ...
    }
}

Filing cabinet Compras.Cs:

namespace Projeto.Forms {
    public class ComprasForm : Form {
       ...
    }
}

Filing cabinet Customer.Cs:

namespace Projeto.Forms {
    public class ClienteForm : Form {
       ...
    }
}

In a fourth file, Mainform.Cs, I would have accessed the three classes only by references Projeto.Forms:

using Projeto.Forms;

namespace Projeto {
    public class ContasForm : Form {
       private ContasForm contasForm;
       private ComprasForm comprasForm;
       private ClienteForm clienteForm;
    }
}

Already in Delphi this does not occur:

Filing cabinet Projeto.Forms.Contas.pas:

unit Projeto.Forms.Contas;
interface
uses ...
type
  TContasForm = class(Form)
  ...

Filing cabinet Projeto.Forms.Compras.pas:

unit Projeto.Forms.Compras;
interface
uses ...
type
  TComprasForm = class(Form)
  ...

Filing cabinet Project.Forms.Client.pas:

unit Projeto.Forms.Cliente;
interface
uses ...
type
  TClienteForm = class(Form)
  ...

Anyway, when wanting to refer them to Project.Forms.Mainform I need to do as follows:

unit Projeto.Forms.MainForm;
interface
uses Projeto.Forms.Contas, Projeto.Forms.Compras, Projeto.Forms.Cliente;
type
  TMainForm = class(Form)
  ...

Not it is possible to do something like uses Projeto.Forms; and from there have access to the three classes. Much less is it allowed in Delphi to have more than one file with the same name.

The only way I’ve seen of having such a benefit would be to manipulate. Example:

Create another Unit with the name Projeto.Forms.pas:

unit Projeto.Forms;
interface
type
  TContasForm = Projeto.Forms.Contas.TContasForm;
  TComprasForm = Projeto.Forms.Compras.TComprasForm;
  TClienteForm = Projeto.Forms.Cliente.TClienteForm;
...

And then make the reference as I had quoted, uses Projeto.Forms; and then have access to the three classes.

Well, I don’t know if that would have consequences and, of course, it was just to illustrate.

In light of this, I ask: What are the advantages of using namespaces in Delphi?

I ask for a small example just to illustrate.
Grateful!

Answer 1

Advantages of using namespaces in Delphi

Namespaces in Delphi aim to organize Units and types logically.

Namespaces also serve to offer a global unique identifier for a type or Unit, so we can have more than one type or Unit with the same name in the same project.

In a large system, it is not uncommon that different Units or types of different contexts naturally bear the same name.

For example, a product in stock may be a distinct entity from the product in the sales front-end (see DDD - bounded context). Namespaces allow us to actually call both entities "Product", with different namespaces, providing a nomenclature more expressive and closer to the business, without having to forge prefixes and suffixes to differentiate Units and types of different contexts.

In addition, there is more clarity in calling a Unit Business.Estoque.Produto than BusinessProdutoEstoque.

Differences between Delphi namespaces and C Sharp namespaces

An important difference between C# namespaces and Delphi namespaces is that in C# they group types, and in Delphi they group Units and Units they group types (each Unit is a source file).

So in C#, to bring into context all kinds of a namespace, we do this:

using Business.Estoque.Produto;

Now, all types of this namespace that are referenced by the project will be immediately available in context.

In Delphi, the above command (would be you use instead of using) would be referencing Unit Business.Estoque.Product namespace Business.Stock., bringing to context all types declared in this Unit.

Similarity between Delphi namespaces and Java namespaces

If in the project the practice is to declare only a single public type in each file, in this aspect Delphi namespaces are more similar to Java namespaces (where they are called Packages), because in Java the source file has the name of the public class contained in it, and the default is to reference not a namespace so as to bring all its types into context, but rather to reference each of the classes you want to bring into context.

In Java, the command import Business.Estoque.Produto brings to context only the class Product, such as in Delphi would be bringing only, say, a class called Tproduct (contained in Unit Product).

Here, Java has a resource that Delphi does not have. In Java there is the option to bring all types of namespace into context at once:

import Business.Estoque.*;

In the above command, not just such a class Product but also all classes of namespace Business.Stock. will be available in context. Delphi does not have this feature, so each namespace Unit Business.Stock. would have to be referenced explicitly, example:

uses Business.Estoque.Produto, Business.Estoque.Produto.Categoria,
    Business.Estoque.Inventario;

Completion

Delphi namespaces have the same goal as in C# or Java: logically organizing the project, with the benefit of being able to have global unique identifiers for types or Units with equal names.

The most important difference is that while in C# or Java a namespace (in java, package) groups types, in Delphi a namespace groups Units and Units groups types.

In Java, it is common to explicitly reference each type, but it is also possible to reference all types of a namespace at once using the *joker. In Delphi the only option is to explicitly reference each Unit.

While not simplifying the reference to types in context (not allowing one-time referencing of types contained in several Units), namespaces in Delphi still offer the advantage of logically organizing the project, allowing more expressive names for Units and types.

For example, instead of having in my code Units and guys with names like CategoriaCliente, CategoriaProduto, CategoriaFrete... I may have Vendas.Cliente.Categoria, Estoque.Produto.Categoria, Transporte.Frete.Categoria.