Dynamics 365 Business Central and AL language: it’s the time to give us namespaces!

Naming objects is one of the hardest problems in software development. In programming, a namespace is a technique used to uniquely identifying one or more objects from other similarly named objects. A namespace defines a scope where identifiers like variables, functions, obejcts, etc., are declared. The main purpose of using a namespace is to prevent ambiguity when two identifiers have the same name.

Every programming language borned to support large projects and to support modularity, must support namespaces. Every modern programming language nowadays supports namespaces. In C# for example, I can write something like the following:

System.Convert.ToInt32("123");
SD.Convert.ToInt32("123")

Where the first is the Microsoft implementation of a method (The Convert class is a class that converts a base data type to another base data type) while the second is my custom method in my custom Convert class.

In programming languages lacking language support for namespaces, namespaces can be emulated by using naming convention identifiers. This technique (trick) has a lot of problems and limitations compared to advantages.

Now, where is AL in this scenario?

AL is a programming language for business applications that does not support namespaces and uses custom indentifiers to avoid objects collisions. I think that everyone of you know that to publish an AL extension on AppSource, but also if you want to create a per-tenant extension that avoid objects collisions between apps as more as possible, you need to use affixes in your object names. And in AL language affixes must be used everywhere:

• Every new object (table, page etc)
• Every new extension object (tableextension, pageextension etc)
• Every field on extended tables
• Every group, field, action added on extended pages
• Every public function
• Every event added on public objects
• … (no full list here)…

Affixes creates headaches on checking code rules (cops), on naming objects (the 30 character limits is a pain with affixes that normally are 3 registered digits + N custom digits) and so on.

When AL language was borned, I remember that there was an internal discussion in MS about affixes on object names and they was intended as a “temporary solution” for a more brilliant future to come. But now we’re in 2023 (few days missing) and we’re here again with affixes on names and with a continuos work by the AL team to add rules and pragmas in the ALC compiler to check for object names uniqueness.

The last news I saw yesterday was this: the next version of the AL extension will check for uniqueness of global variables (We have added validation of affixes and breaking changes for global variables (changing name, type, accessibility, etc).).

There’s a huge work from Microsoft to discover breaking changes due to possible objects collisions caused by affixes.

Now my question is: after N years, why not seriously working on supporting namespaces in AL?

I think that a first support level of namespaces (maybe not nested namespaces but a single namespace for app) could be not impossible to implement also at the compiler level and this could increase a lot the developer experience.

Why not doing something like this?

We can define in the app.json file a namespace for app (where the root can be registered in Microsoft as usual). Then, I can write all the AL code without problem of naming objects. I can for example create a custom Customer table or extend a standard Customer List page:

Here the Customer table belongs to the SD.MyDemoExtension namespace and it’s a different object then the Customer table defined by Microsoft (that maybe belongs to the Microsoft namespace).

The ALC.exe compliler should check for namespaces and translate all the symbols like:

• Microsoft.Customer for the standard Customer table
• SD.MyDemoExtension.Customer for my custom Customer table
• SD.MyDemoExtension.CustomerListExt for my Customer List pageextension object

and so on for every object added in a custom extension.

I know that we can do more than this with namespaces, but this could be a quite easy beginning I think.

Why there’s not a huge work on this topic? I think this should have an highest priority, because the limitations of using affixes are always more visible and difficult to avoid also for the MS team.

Asking this for Santa… 😉