Business Central 2023 wave 2 (BC23): Segment AL code and reduce naming conflicts with namespaces (Namespaces in AL)

Hi, Readers.
The public preview for Dynamics 365 Business Central 2023 release wave 2 (BC23) is available. Learn more: Link.

I will continue to test and share some new features that I hope will be helpful.

Segment AL code and reduce naming conflicts with namespaces:

Business value:
AL for Business Central will now support namespaces, similar to other code languages. Namespaces provide a way of organizing objects and code in a logical and hierarchical manner. They can be used to help avoid naming conflicts between different extensions, making it easier to maintain and understand extensions, including the relationship between different objects.

https://learn.microsoft.com/en-us/dynamics365/release-plan/2023wave2/smb/dynamics365-business-central/segment-al-code-reduce-naming-conflicts-namespaces

In computing, a namespace is a set of signs (names) that are used to identify and refer to objects of various kinds. A namespace ensures that all of a given set of objects have unique names so that they can be easily identified. More details: Namespace

From Business Central 2023 wave 2 (runtime”: “12.0”), an AL file can now define a namespace at the top, which will apply to all objects in the code file.

A given object can only belong to one namespace.

But the same namespace can be used for multiple AL files and objects.

This is similar to namespace in C# and other program language. More details: Declare namespaces to organize types

So how does that affect us? Let’s look at a simple example.

I have two variables declared in a test codeunit, one for the Customer table and one for the system codeunit Math. This is what NAV and BC developers have always done.

But let’s see what happens when we add a namespace. Yes, standard objects such as tables and codeunits will not be found.

Table ‘Customer’ is missing

Codeunit ‘Math’ is missing

Why? In short, this is because the standard objects are not in your custom namespace, e.g. the system does not exist for ZYProject.Customer. They are in a Microsoft standard namespace.

Code actions will be available to help developers add namespaces to existing sources. More details about Using AL Code Actions.
For example,

Fully qualify as ‘Microsoft.Sales.Customer.Customer’:

Add ‘using Microsoft.Sales.Customer‘

So when objects are resolved, the closest scope is used first. Therefore, to resolve to a similarly named object in a dependent extension, the reference must use a fully qualified name. Alternatively, it’s possible to define using directives to include external namespaces and thereby omit fully qualifying names.

Because namespaces are useful for logical segmentation of extensions, the AL Explorer also shows namespaces for objects and allows grouping objects by namespace, making it easier to discover related objects, focus on app subareas, and identify inconsistencies when adding new objects. For example,

page 42 “Sales Order”:

table 18 Customer:

Great improvement for all AL developers. Using namespace allows us to get away from prefix or suffix (Benefits and guidelines for using a prefix or suffix), but as of now, it’s not mandatory and you can customize BC using the original way.
Give it a try!!!😁

PS:
This new feature was also introduced at BC Tech Days 2023.

BC TechDays 2023 – Opening Keynote: 1:12:43~

END

Hope this will help.

Thanks for reading.

ZHU