Feature Request for the Delphi Language (Rethink or Eliminate the Concept of Units)

[dmitrybv 5]

Description:
In Delphi, it's not possible to list units that reference each other in the interface uses section. This limitation significantly hinders class organization within a package. Initially, developers work around this by moving some unit references to the implementation uses section. However, as the class hierarchy becomes more complex, this strategy breaks down.

At a certain point, class inheritance and cross-referencing between units can no longer evolve naturally due to circular reference restrictions. Instead of focusing on building a clean and scalable architecture, developers are forced to spend an excessive amount of time carefully juggling interface and implementation references across units to avoid dependency issues.

 

Suggestion:
Consider removing the concept of unit as a fundamental structural element in Delphi’s object model, and instead rely entirely on package-based architecture. Classes within the same package should be able to access each other regardless of which unit they reside in, without exposing their internal structure outside the package.

If this change is too radical for Delphi’s current model, a more incremental alternative could be introduced:
Allow splitting of interface/implementation code across multiple files, which could then be merged by the compiler or a preprocessor into a single internal unit. This would simulate package-level cohesion without breaking existing language design principles.

[Dalija Prasnikar 1511]

This has only been an issue if you make a mess out of your code design. In rare situations where you do need circular references using implementation section in one unit will suffice. I doubt that proposed changes would bring too much overall benefit and they would require extensive rework of the existing compiler architecture. 

 

There is existing feature which would be more beneficial for code organization: class helpers. Currently there is only a single supported helper in scope and having multiple ones would allow breaking down more complex code and organizing it into separate files. Implementing those would be a much simpler task, consistent with the existing architecture.

[DelphiUdIT 243]

@dmitrybv

The concept you express, that of simplifying the organization of the code in some way, has been discussed several times (so much so that now we can build the view of the "link" tree).

However, the current organization, in my humble opinion, allows us to maintain a well-separated and at the same time compact organization of the code.
The concept of "breaking" the code into unitary elements fits perfectly with the concept of units. It also fits with the concepts of scope (private / strict private / ...) and how they are now applied.

The problem of "blocking" circular references is actually a problem that concerns the implementation of the code not carried out with rigor.
Out of haste or inexperience, everything is put into a few units and then ... "you can't unring the bell".
 

The concept of packages is already present (see third-party distributions or even bundles like Indy or FireDAC) but the use is still tied to units, and so you can "load" only what is necessary without having to compile the entire package, ensuring a fast and compact generation (... compact ... 🙂maybe it could be improved) of the executable code. For the runtime the concept of packages is already present similarly to other "languages".

Of course, it is necessary to know what to reference as a unit but it is a hurdle that is easily overcome with time ... and it also helps to understand how the package was conceived and organized (which never hurts).

Edited yesterday at 08:14 AM by DelphiUdIT

[Uwe Raabe 2156]

6 minutes ago, DelphiUdIT said:

Out of haste or inexperience, everything is put into a few units and then ... "you can't unring the bell".

Well, in this case you can. I did a lot of refactoring such code myself during the last decades. The constraint you suggested to remove is a good indicator of progress in such an endeavor.

[Brandon Staggs 383]

15 hours ago, dmitrybv said:

Consider removing the concept of unit as a fundamental structural element in Delphi’s object model, and instead rely entirely on package-based architecture.

You may as well just stuff all your classes into a single unit so you can achieve this. You don't need the language to undergo a fundamental redesign.

 

As projects grow the issues with circular references can become annoying. I know this well. But the solution is to do better class design, not to embrace the excessive coupling of the classes.

[mjustin 28]

11 hours ago, Uwe Raabe said:

Well, in this case you can. I did a lot of refactoring such code myself during the last decades. The constraint you suggested to remove is a good indicator of progress in such an endeavor.

I enjoyed reading your contributions on SO and your blog posts on this topic, for example https://www.uweraabe.de/Blog/2010/08/16/the-visitor-pattern-part-2/ ("The Visitor Pattern – Part 2"), which I think are a essential reading:

Quote

As the shapes reference the visitor and the visitor references the shapes we have to put all shape classes together with the visitor into the same unit. Although this might work in some smaller scenarios, it definitely doesn’t in most of the real ones. (...) How can we break this up? The answer are interfaces! Instead of declaring a visitor capable of handling every defined shape, we declare an interface for each shape that only handles that specific shape.