Nombrar objetos es uno de los problemas más difíciles en el desarrollo de software. En programación, un espacio de nombres es una técnica utilizada para identificar de forma única uno o más objetos de otros objetos con nombres similares. Un espacio de nombres define un dominio en el que se declaran identificadores como variables, funciones, objetos, etc. El objetivo principal de usar un espacio de nombres es evitar la ambigüedad cuando dos identificadores tienen el mismo nombre. Sigue leyendo si quieres saber más sobre formación en dynamics 365.
Cada lenguaje de programación nacido para admitir grandes proyectos y admitir la modularidad debe admitir espacios de nombres. Todos los lenguajes de programación modernos admiten espacios de nombres en estos días. En C#, por ejemplo, puedo escribir algo como lo siguiente:
System.Convert.ToInt32("123");
SD.Convert.ToInt32("123")
Donde el primero es la implementación de Microsoft de un método (El Convertir class es una clase que convierte un tipo de datos básico en otro tipo de datos básico) mientras que el segundo es mi método personalizado en mi Convertir clase.
En los lenguajes de programación que no admiten el lenguaje de espacio de nombres, los espacios de nombres se pueden emular mediante identificadores de convenciones de nomenclatura. Esta técnica (truco) tiene muchos problemas y limitaciones en comparación con las ventajas.
Ahora, ¿dónde está AL en este escenario?
AL es un lenguaje de programación para aplicaciones comerciales que no admite espacios de nombres y utiliza identificadores personalizados para evitar colisiones de objetos. Creo que todos saben que para publicar una extensión AL en AppSource, pero también si desean crear una extensión por inquilino que evite en la medida de lo posible las colisiones de objetos entre aplicaciones, deben usar afijos en los nombres de sus objetos. Y en el idioma AL, los afijos deben usarse en todas partes:
- Cada nuevo objeto (tabla, página, etc.)
- Cada nuevo objeto de extensión (extensión de tabla, extensión de página, etc.)
- Cada campo en tablas extendidas
- Cada grupo, campo, acción agregada en páginas extendidas
- Cada oficina pública
- Cada evento agregado en objetos públicos
- … (no hay una lista completa aquí)…
Los afijos crean dolores de cabeza al verificar las reglas del código (policías), nombrar objetos (los límites de 30 caracteres son una molestia con afijos que normalmente son 3 dígitos registrados + N dígitos personalizados), etc.
Cuando nació el lenguaje AL, recuerdo que hubo una discusión interna en MS sobre los afijos en los nombres de los objetos, y estaban pensados como una «solución temporal» para un futuro mejor. Pero ahora estamos en 2023 (a unos días de distancia) y aquí estamos nuevamente con afijos de nombres y el trabajo continuo del equipo de AL para agregar reglas y pragmas al compilador de ALC para verificar la singularidad de los nombres de los objetos.
La última noticia que vi ayer fue esta: la próxima versión de la extensión AL verificará la unicidad de las variables globales (WSe agregó validación de afijos y cambios importantes para variables globales (cambio de nombre, tipo, accesibilidad, etc.).).
Hay una gran cantidad de trabajo por parte de Microsoft para descubrir cambios rotos debido a posibles colisiones de objetos causadas por afijos.
Ahora mi pregunta es: después de N años, ¿por qué no trabajar seriamente en ello? admite espacios de nombres en AL?
Creo que un primer nivel de soporte para espacios de nombres (quizás no espacios de nombres anidados, sino un solo espacio de nombres para la aplicación) también podría ser imposible de implementar en el nivel del compilador, y esto podría mejorar en gran medida la experiencia del desarrollador.
¿Por qué no hacer algo así?
Podemos definir en el archivo app.json un espacio de nombres para la aplicación (donde la raíz se puede registrar con Microsoft como de costumbre). Entonces puedo escribir todo el código AL sin la molestia de nombrar objetos. Por ejemplo, puedo crear un personalizado Cliente mesa o extender un estándar Lista de clientes página:
Aquí Cliente la mesa pertenece SD.MyDemoExtension espacio de nombres y es un objeto diferente que el Cliente tabla definida por Microsoft (que puede pertenecer a microsoft espacio de nombres).
El compilador ALC.exe debe verificar los espacios de nombres y traducir todos los símbolos como:
- Microsoft.Cliente para el estándar Cliente mesa
- SD.MyDemoExtension.Client por mi costumbre Cliente mesa
- SD.MyDemoExtension.CustomerListExt para mi Lista de clientes objeto de extensión de página
y así sucesivamente para cada objeto agregado a una extensión personalizada.
Sé que podemos hacer más que eso con los espacios de nombres, pero creo que esto podría ser un comienzo bastante fácil.
¿Por qué no hay una gran cantidad de trabajo sobre este tema? Creo que esto debería tener la máxima prioridad porque las limitaciones del uso de afijos son siempre más visibles y difíciles de evitar también para el equipo de MS.