X++ in AX7: Readonly keyword

In AX7 X++ now supports the readonly keyword. Semantically it is identical to readonly in C#. In short; it allows you to define members on a class that can only be initialized in the declaration and in the constructor. class MyClass {     readonly str identifier = "XYZ";     readonly str identifier2;     public void new(str _identifier)     {         identifier2 = _identifier;     }     public void foo()     {         // The field 'identifier2' is read only. A value cannot be assigned to it.         //identifier2 = "ABC";      } }

The big question is "when to use it?" In my opinion the actual use scenarios are limited – simply because other language constructs are still missing.


In X++ we still recommend the construct pattern and the newFrom pattern. These patterns recommend the new method to not have any parameters – readonly has little applicability, when the new method is parameter-less.



So why do we prefer parameter-less new methods?

1. It enables serialization of classes using the pack/unpack pattern – all classes extending RunBase are subject to this.
2. It enables the extension framework and smart customizations.

Once X++ supports getters/setters and method overloading (at least of the new method) – then readonly will become handy.'


If you have a good use scenario for readonly - please share in the comments section below.

X++ in AX7: Readonly keyword

In AX7 X++ now supports the readonly keyword. Semantically it is identical to readonly in C#. In short; it allows you to define members on a class that can only be initialized in the declaration and in the constructor. class MyClass {     readonly str identifier = "XYZ";     readonly str identifier2;     public void new(str _identifier)     {         identifier2 = _identifier;     }     public void foo()     {         // The field 'identifier2' is read only. A value cannot be assigned to it.         //identifier2 = "ABC";      } }

The big question is "when to use it?" In my opinion the actual use scenarios are limited – simply because other language constructs are still missing.


In X++ we still recommend the construct pattern and the newFrom pattern. These patterns recommend the new method to not have any parameters – readonly has little applicability, when the new method is parameter-less.



So why do we prefer parameter-less new methods?

1. It enables serialization of classes using the pack/unpack pattern – all classes extending RunBase are subject to this.
2. It enables the extension framework and smart customizations.

Once X++ supports getters/setters and method overloading (at least of the new method) – then readonly will become handy.'


If you have a good use scenario for readonly - please share in the comments section below.

X++ in AX7: Extension methods

Have you ever experienced a Microsoft provided class or table missing that vital method that would just make your life easier? If so, you might have been tempted to add it yourself using overlayering. And you surely have paid the upgrade price!


You are about to be pleased. In AX7 X++ supports extension methods, similarly to C#.
Suppose we want to add a fullName method to the DirPersonName table. Here is how you do it, without touching the DirPersonName table. Create this new class:



static class MyDirPersonName_Extension
{
    static public PersonName fullName(DirPersonName _person)
    {
        return strFmt('%1 %2 %3', _person.FirstName, _person.MiddleName, _person.LastName);
    }
}  


Things to remember:

1. The class must be postfixed with "_extension".
2. The class must be static.
3. The extension methods must be static.
4. The type of the first parameter determines which type is extended.

Now you can enjoy your extension method:


DirPersonName dirPersonName;

while select dirPersonName
{
    info(dirPersonName.fullName());
} 


Notice:

1. When calling extension methods, you don't provide the first parameter – that gets inferred from the instance's type.
2. If the extension method took any additional parameters – they (of course) needs to be provided.
3. This doesn't break encapsulation. The extension method only has access to public fields and methods on the type.

X++ in AX7: Extension methods

Have you ever experienced a Microsoft provided class or table missing that vital method that would just make your life easier? If so, you might have been tempted to add it yourself using overlayering. And you surely have paid the upgrade price!


You are about to be pleased. In AX7 X++ supports extension methods, similarly to C#.
Suppose we want to add a fullName method to the DirPersonName table. Here is how you do it, without touching the DirPersonName table. Create this new class:



static class MyDirPersonName_Extension
{
    static public PersonName fullName(DirPersonName _person)
    {
        return strFmt('%1 %2 %3', _person.FirstName, _person.MiddleName, _person.LastName);
    }
}  


Things to remember:

1. The class must be postfixed with "_extension".
2. The class must be static.
3. The extension methods must be static.
4. The type of the first parameter determines which type is extended.

Now you can enjoy your extension method:


DirPersonName dirPersonName;

while select dirPersonName
{
    info(dirPersonName.fullName());
} 


Notice:

1. When calling extension methods, you don't provide the first parameter – that gets inferred from the instance's type.
2. If the extension method took any additional parameters – they (of course) needs to be provided.
3. This doesn't break encapsulation. The extension method only has access to public fields and methods on the type.