Skip to main content

Notifications

Dynamics 365 Community / Blogs / Peter's X++ developer Blog / New classes are internal by...

New classes are internal by default.

Peter Villadsen Profile Picture Peter Villadsen

We have recently made some changes in our Visual Studio tooling so new classes are marked as internal by default. Some of you have already seen this, while others will have to wait until it gets to final release through our delivery process.

The reason we did this is probably obvious: Most classes really should be internal (i.e., only be consumable within the package they are defined) because if a class is public (which is still the case if no other modifier is provided) it is almost impossible to make changes to that class later, since, over time, there is a risk that others have taken dependencies on it. Developers should be very particular about what you allow people to take dependencies on; you want to protect your implementation details and be mindful of your contract with consumers of your code artifacts. This is just good software engineering practice.

Even before this change, methods added by the Visual Studio tooling are made private by default, for exactly the same reason. And, by the way, the tooling for C# does the same thing, both for classes and methods.

Just to hammer home the message: We added the internal keyword as a default because then you don't have to. You are free to remove the internal keyword if you need to make your class public.

Comments

*This post is locked for comments

  • HarryDesh Profile Picture HarryDesh 65
    Posted at
    Nice job! even customer account statement base classes are internal. Every customer needs some additional fields so now we have a huge perf issue because we have to populate them later. No wonder people are just copying class hierarchy because Microsoft is making so many classes internal.
  • PujaS Profile Picture PujaS 7
    Posted at
    Do we know this change will be a part of which release by MS? Also is MS planning to make internal mandatory in future?
  • Von Paul Profile Picture Von Paul
    Posted at
    if MS is so in love with their code and putting so many roadblocks to customers, this will diminish a lot from the appeal of the platform. As people extending AX, this is quite UNACCEPTABLE to us. this coming from AX 2012, where customers were able to change ALL code except core code. That was the beauty of the platform. If MS forgets that, then maybe usage will be diminished. Who decides/vets this things at MS???
  • Szabolcs Eotvos Profile Picture Szabolcs Eotvos
    Posted at
    Hi Peter! What about refactoring/obsoleting scenarios? Let's say you have a standard class marked as public and it is already customized by customers/ISVs/VARs. You want to refactor it and add a new class which is now internal by default. This new functionality is introduced to the feature management and flight frameworks so it depends on the lifecycle stage how this new functionality behaves. In other words customers/ISVs/VARs are not in control of these features but MSFT is. They can get stuck and wait for an extension request to properly handle the new functionality with their already existing customization which was working just fine with the old public class. in the intermittent period the end user can end up in a functionality loss or at minimum they need to do some manual work, depending on the lifecycle stage that they still use the old functionality not the new one, until these extension requests are sorted.
  • _Frank Profile Picture _Frank 15
    Posted at
    Maybe you should also add a todo to the template, to remind developers to think about a public API to the class, just to let them think about whether there might be others that want to use or extend the class. Because I think you cannot directly compare C# to X++ in regards for what it is most commonly used [emoticon:4191f5ee34e248a29fa0dbe8d975f74a]