Recent

Author Topic: Interface/Implementation and 'Uses' Statement  (Read 7561 times)

trayres

  • Jr. Member
  • **
  • Posts: 92
Interface/Implementation and 'Uses' Statement
« on: March 04, 2015, 07:56:06 am »
If I say
Code: [Select]
Interface
uses Classes;

instead of
Code: [Select]
Implementation
uses Classes;

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: [Select]
unit Classes;

interface

uses
  rtlconsts,
  sysutils,
  types,
{$ifdef FPC_TESTGENERICS}
  fgl,
{$endif}
  typinfo,
  windows;
               

And later:
Code: [Select]
implementation

uses
  sysconst; 

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

  • Hero Member
  • *****
  • Posts: 5368
Re: Interface/Implementation and 'Uses' Statement
« Reply #1 on: March 04, 2015, 08:48:28 am »
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.
Good judgement is the result of experience … Experience is the result of bad judgement.

OS : Windows 7 64 bit
Laz: Lazarus 1.4.4 FPC 2.6.4 i386-win32-win32/win64

howardpc

  • Hero Member
  • *****
  • Posts: 4144
Re: Interface/Implementation and 'Uses' Statement
« Reply #2 on: March 04, 2015, 09:59:30 am »
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

  • Hero Member
  • *****
  • Posts: 905
    • homepage
Re: Interface/Implementation and 'Uses' Statement
« Reply #3 on: March 04, 2015, 12:10:53 pm »

The tighter the syntax and the scope of variable use, the easier it is to identify and eliminate bugs.

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

  • Jr. Member
  • **
  • Posts: 92
Re: Interface/Implementation and 'Uses' Statement
« Reply #4 on: March 07, 2015, 08:13:33 am »
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.

eny

  • Hero Member
  • *****
  • Posts: 1634
Re: Interface/Implementation and 'Uses' Statement
« Reply #5 on: March 07, 2015, 01:34:57 pm »
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.
It's a very questionable example  %)
All posts based on: Win10 (Win64); Lazarus 2.0.10 'stable' (x64) unless specified otherwise...

 

TinyPortal © 2005-2018