| **Navigation:**  [[introduction.htm|Language Reference]] > 2 - Program Source Code Format > Procedure Overloading >====== Rules for Procedure Overloading ====== | [[procedure overloading.htm|{{btn_prev_n.gif|Previous page}}]][[introduction.htm|{{btn_home_n.gif|Return to chapter overview}}]][[name mangling and c   compatibility.htm|{{btn_next_n.gif|Next page}}]] |
|  ||

The Clarion language has built-in data type conversion which can make overload resolution difficult for the compiler. Therefore, there are rules governing how the compiler resolves functional overloading, which are applied in the following order:

1.Entity-parameters are resolved to FILE, KEY, WINDOW, and QUEUE. If a prototype can be chosen on the basis of these alone then the compiler does (most of the Clarion built in procedures fall into this category). Note that KEY and VIEW are implicitly derived from FILE, just as APPLICATION and REPORT are implicitly derived from WINDOW.

2.All "named group" parameters must match a group of their own structure. Procedure-parameters are matched by structure. CLASSes must match by name, not simply by structure.

3.A prototype must match in the number and placement of non-omittable parameters. This is the third criteria (not the first) so that the compiler can usually guess which prototype the user was aiming at and give a more meaningful error message.

4.If there are no matching prototypes then allow derivation. At this point a KEY would be allowed to match a FILE and a group that is derived would match one of its base classes. If one level of derivation does not work, the compiler continues up the tree. All QUEUEs now match QUEUE and GROUP etc. CLASSes derive before other parameter types.

5.Variable-parameters (unnamed) must exactly match the actual data type passed. A *GROUP matches a *STRING. Any variable-parameter matches *?.

6.All Value-parameters are considered to have the same type**.**

**Example:**

** MAP**

**Func  PROCEDURE(WINDOW)     ! 1**

**Func  PROCEDURE(FILE)       ! 2**

**Func  PROCEDURE(KEY)        ! 3**

**Func  PROCEDURE(FILE,KEY)   ! 4**

**Func  PROCEDURE(G1)         ! 5**

**Func  PROCEDURE(G0)         ! 6**

**Func  PROCEDURE(KEY,G0)     ! 7**

**Func  PROCEDURE(FILE,G1)    ! 8**

**Func  PROCEDURE(SHORT = 10) ! 9**

**Func  PROCEDURE(LONG)       ! 10**

**Func  PROCEDURE()           ! Illegal, indistinguishable from 9**

**Func  PROCEDURE(*SHORT)     ! 11**

**Func1 PROCEDURE(*SHORT)**

**Func1a PROCEDURE(*SHORT)**

**Func2 PROCEDURE(*LONG)**

**Func  PROCEDURE(Func1)      ! 12**

**Func  PROCEDURE(Func1a)     ! Illegal, same as 12**

**Func  PROCEDURE(Func2)      ! 13**

** END**

**G0 GROUP**

**  END**

**G1 GROUP(G0)**

**  END**

** CODE**

** Func(A:Window)   ! Calls 1 by rule 1**

** Func(A:File)     ! Calls 2 by rule 1**

** Func(A:Key)      ! Calls 3 by rule 1**

** Func(A:View)     ! Calls 2 by rule 4**

** Func(A:Key,A:Key)! Calls 4 by rule 4 (would call key,key if present)**

** Func(A:G0)       ! Calls 6 by rule 2**

** Func(A:G1)       ! Calls 5 by rule 2**

** Func(A:Func2)    ! Calls 13 by rule 2**

** Func(A:Key,A:G1) ! Error - Ambiguous. If rule 4 is used then 7 & 8 are both possible**

** Func(A:Short)    ! Error - Ambiguous. Calls 9 or 11**

** Func(A:Real)     ! Calls 9 by rule 6**

** Func             ! Calls 9 by rule 3**

**See Also:**

[[class  object declaration .htm|CLASS]]