Enhancement suggestion: codeunitinterface object type

[vjekob]

Extensions often require some kind of polymorphic behavior. Currently we have to struggle with this through events, but it often results in a lot of code, sometimes poor performance, not to mention exposure to all sorts of vulnerabilities.

I am proposing an introduction of a new object type: codeunit interface. It would allow something like this to be written:

And this is what an interface declaration and implementation could look like:

The "Implements" property should allow specifying multiple interfaces, of course.

[rickblommetjes]

Sounds as a solid and great idea.

[ptijsma]

This would really be great to have!

[naradae]

Wholehearted agreement. It will be so hard to achieve sane extensibility if we don't have real and straight-forward polymorphism

[TihanaLapas]

This is a great idea! I hope it will be accepted.

[waldo1001]

I don't know what it means to get this in the language - but I want it! ;-)

[pborring]

We are tracking the concept in the backlog today, but with no commitment timeline.

This could be on object/code unit level (as above) as well as on a larger contract level for a "module" (e.g., supporting a plugable pattern for, e.g., tax calculation or item costing). The latter would need some base application rewrite, where the former would be useful for ISV and VAR partners out of the box, as described with the ICar example above.

If not already, please consider adding idea to Ideas site to allow voting and providing feedback on it. http://aka.ms/bcideas

[ptijsma]

We are tracking the concept in the backlog today, but with no commitment timeline.

This could be on object/code unit level (as above) as well as on a larger contract level for a "module" (e.g., supporting a plugable pattern for, e.g., tax calculation or item costing). The latter would need some base application rewrite, where the former would be useful for ISV and VAR partners out of the box, as described with the ICar example above.

If not already, please consider adding idea to Ideas site to allow voting and providing feedback on it. http://aka.ms/bcideas

Ehhmm. What's the idea about this site @pborring ?

[vjekob]

@ptijsma Simply remove the /categories/list part of the final URL, and you are there.

@pborring What about that site? I can only make functional product suggestions, the site has no category for AL improvements…

[vjekob]

@pborring Thanks for confirming this to be in your backlog, but I think that at least for the time being, you should not really be looking at your described module-level enhancement. A much simpler enhancement of type I describe would provide huge benefits for ISV/VAR partners, while not requiring you guys to change anything in the base application.

[nicolassaleron]

I love this proposal !

What about a TableInterface? This is not exactly the same purpose but if we had INoSeries, IDocumentHeader, ILedgerEntry, IDimension : we would be able to simplify features that work the same way no matter the record type. For instance, Navigate or Ledger Entry Application which are either a long CASE for each record type or duplicated features. It would become possible for an extension A to work with a record from extension B without a direct dependency....

[bjarkihall]

For those who didn't see it demoed at NAV TechDays: https://youtu.be/pl0LAvep6WE?t=4646

[pborring]

Closing this as interfaces are supported in BC 2020 Wave 1, available for partners to use, as well as being used in the base app going forward (e.g., PriceCalculation in BC 2020 Wave 1).

For any additional support around interfaces, please create entries on Ideas https://aka.ms/bcideas and vote.