Reputation: 2027
If I put a unit in the uses clause of the implementation section of a unit, the identifiers declared in such unit are not available to the interface section.
What is the advantage of doing that and not being able to use identifiers from the referred unit in the interface?
Is there any practical advantage (such as avoiding unwanted side effects) if you bother to add used units in the implementation section instead of simply doing it the interface section?
Upvotes: 6
Views: 429
Reputation: 597016
Adding a unit to the uses
clause of the implementation
section allows that unit to be a private dependency only to the implementation
, not to the interface
. If UnitA uses UnitB, but no one outside of UnitA cares whether UnitA uses UnitB, because UnitA's interface does not use UnitB, then why advertise the dependency and clutter the interface
? Also, if you ever need to remove UnitB and/or replace it with something else, declaring it in the uses
clause of the implementation
section avoids an interface
change that would affect any unit that is using UnitA.
Upvotes: 13
Reputation: 613232
The biggest issue is that uses in the interface section can lead to circular dependencies and compilation failure. If unit A uses unit B in the interface section, then unit B cannot use unit A in its interface section.
So, you are often forced into putting at least some uses into the implementation section.
Otherwise I personally prefer to put unit uses into the interface section if at all possible. The main reason being one of scoping and hiding. If there are name scoping clashes (two units define the same name, and the second use hides the first) then rather the same name was in scope throughout the entire unit.
Upvotes: 5