Uncategorized

Codeunit Interfaces – this time for real!

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

3 thoughts on “Codeunit Interfaces – this time for real!”

  1. 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.

    1. 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.

Leave a Reply