There is a particular programming language feature that I’ve always missed in AL (and C/AL for that matter): interfaces. I’ve dreamt about it, then blogged about it, then finally created a feature request in Microsoft’s AL GitHub repository. My GitHub feature request caught quite some traction and became the most upvoted feature request in less than a day.
Now, I don’t know if or to what extent it was my submission that influenced Microsoft, but it doesn’t really matter – what matters is that it’s becoming reality. Last week at NAV TechDays, Microsoft has presented an amazing new feature that will be coming to AL pretty soon: interface object type. And it’s official, or at least as official as Microsoft’s keynote is, and you can check Microsoft’s demo yourself at https://youtu.be/pl0LAvep6WE?t=4646
The feature is far more comprehensive than anyone could have hoped for, and it can be used for codeunits and enums, and in the future maybe even for a few more things. Who knows, or dares to dream. I dared, and I am pretty happy I did
Pingback: Codeunit Interfaces – this time for real! - Microsoft Dynamics NAV Community
There is no need for the ‘interface’ for data in NAV. We are dealing with tables with fixed number of columns, not classes. The “car/bus/truck” thing will never occur in NAV – there will be a “Vehicle Type” field.
Also it will not solve the “enum” problem as well (demonstrated feature looks like unfinished concept-only mess). “CASE EnumField … ELSE CallEnumEvent(EnumField) END” would work better.
Interfaces in proper OOP language exists to force developer to create a set of methods for interoperability between several classes (end vice versa), not several records in the table.
I disagree. I am not talking about interfaces for data, I am talking about interfaces for codeunits. And while you may not see a case for “car/bus/truck” when implementing functionality, I can hardly wait for interfaces to go live, because I have so many use cases where interfaces are the correct solution, and current situation with events is not clean.
Regarding enums, I am not sure how clean of a solution that is, either, but I see why Microsoft wants this, and how this can be useful.
A good example of how an interface could be really useful could be the tax calculations.
If there was a “Tax Calculator” interface that had certain required calcs (start calculation, calculate lines, finish calculation) and in the setup we can specify the tax codeunit id, then as long as the codeunit fits the interface we can swap out one codeunit for another.
With the new codeunit interfaces, is there a way to specify a codeunit id? (and bypass explicit dependencies and get loose coupling?)