Forum > General
Interface/Implementation and 'Uses' Statement
trayres:
If I say
--- Code: ---Interface
uses Classes;
--- End code ---
instead of
--- Code: ---Implementation
uses Classes;
--- End code ---
What exactly is the difference? I'm trying to work out the structure of more complicated Free Pascal programs, like how to interface to Win32 directly.
I am looking at Classes - I notice this:
--- Code: ---unit Classes;
interface
uses
rtlconsts,
sysutils,
types,
{$ifdef FPC_TESTGENERICS}
fgl,
{$endif}
typinfo,
windows;
--- End code ---
And later:
--- Code: ---implementation
uses
sysconst;
--- End code ---
So both have a 'uses' statement.
Can someone help give me a structural understanding of how these two things fit together? Sorry if this is poorly worded, I'm trying to flesh out the idea. :(
taazz:
The idea when first introduced the uses in both sections was that on the interface part you add units that are used from the public face of the unit while on the implementation you put units that you are using but they do not have anything to do with the public face of the unit.
To use your own quoted example units types, typinfo & windows are publishing various types that might be used as input or output for the public classes/procedures in which case are required on the interface section, sysconst on the other hand has a number of error messages that are used only from the implementation so its not needed in the interface. I would argue that rtlconsts is not needed in the interface part either and should be moved to the implementation. Also the two uses clause are used to solve circular references eg if unit A uses unit B and unit B uses unit A then if you put the unit A in the unit's B interface uses clause and unit B in the unit's A implementation uses clause you should not get a circular reference error message.
howardpc:
One of the challenges programmers face is how to manage complex designs well. For very simple programs the distinction in visibility between public and private program elements is not particularly important. There is little danger in every program element being globally accessible by (and having global access to) every other program element.
For programs of even moderate complexity this free-for-all kind of access is disastrous, and can quickly have fatal side effects, especially if you tend to reuse common variable names...
The modularisation of Pascal programs into units as program subsections with public implementation and private implementation parts is the principal way to manage the visibility of entire chunks of code at the language level. It gives you a way to work with the compiler in restricting access in a clear and consistent way, and allows you to define the scope of variables, types, consts and routines unambiguously.
Later developments in the language extended this visibility restriction concept (as applied to units) to classes. This lets you micro-manage visibility in more detail through the use of visibility specifiers within class declarations (strict private, protected etc.), which further reduces the risk of sections of code stepping on each others' toes.
A further step in this direction is the restriction imposed by {$mode objfpc} which disallows repetition of name use in circumstances allowed by {$mode delphi}. Such features, if you use them, also help to avoid accidental spread of visibility beyond what you intend. In general, the sloppier the coding style, the greater the risk of bugs emerging. The tighter the syntax and the scope of variable use, the easier it is to identify and eliminate bugs.
BeniBela:
--- Quote from: howardpc on March 04, 2015, 09:59:30 am ---
The tighter the syntax and the scope of variable use, the easier it is to identify and eliminate bugs.
--- End quote ---
That is why a syntax for block-level variable declarations would be so much better than just procedure-level variable declarations
Now you can never get the tightest scope
trayres:
I also noticed this was partially explained here:
http://wiki.freepascal.org/Form_Tutorial#Passing_Variables_to_Other_Forms
with respect to the interfaces and shared global variables. It suggests a property of a class instead.
Navigation
[0] Message Index
[#] Next page