Guide du typage

version 2004 (Modifiée)

Cette section décrit les principales causes de conflits de types sur les variables, ainsi que les manières de les éviter.

Conflits sur les variables simples

Les conflits de types simples peuvent se résumer comme suit :

• conflit entre deux utilisations,

• conflit entre une utilisation et une directive de compilation,

• conflit par retypage implicite,

• conflit entre deux directives de compilation.

Le conflit de types le plus simple est celui pour lequel un même nom de variable désigne deux objets différents. Imaginez que dans une application, vous écriviez :

   LaVariable:=5

et que, quelque part ailleurs, dans la même application, vous écriviez :

   LaVariable:=Vrai

Vous générez un conflit de types. Le remède est simple : renommez l'une des deux variables.

Imaginez que dans une application, vous écriviez :

   LaVariable:=5

et que, quelque part ailleurs, dans la même application, vous écriviez :

   C_BOOLEEN(LaVariable)

Le compilateur, peignant d'abord les directives de compilation, fera de LaVariable un Booléen mais lorsqu'il découvrira :

   LaVariable:=5

il signalera un conflit de types. Ici encore, le remède est simple : renommez votre variable ou modifiez la directive de compilation.

L'utilisation de variables de types différents dans une expression génère des incohérences. Le compilateur signale très logiquement les incompatibilités. Prenons un exemple simple. Vous écrivez :

   vBooléen:=Vrai    `Le compilateur déduit que vBooléen est de type Booléen
   C_ENTIER(<>vEntier)   `Déclaration d'un Entier par une directive de compilation
   <>vEntier:=3   `Commande compatible avec la directive de compilation
   LaVar:= <>vEntier+vBooléen   `Opération contenant des variables dont les types sont incompatibles

Certaines fonctions renvoient des variables d'un type bien précis. L'affectation du résultat d'une de ces variables à une variable déjà typée différemment provoquera un conflit de types si vous ne faites pas attention.

Dans une application interprétée, vous pouvez écrire :

   No_Ident:=Demander("Numéro d'identification")   `No_Ident est de type Texte
   Si(Ok=1)
      No_Ident:=Num(No_Ident)   `No_Ident est de type Numérique
      CHERCHER([Personnes]Id= No_Ident)
   Fin de si

Vous générez ici un conflit de type sur la troisième ligne. Le remède consiste à contrôler le comportement de la variable. Dans certains cas, vous aurez à créer des variables intermédiaires d'un nom différent. Dans d'autres cas, comme celui-ci en particulier, vous pouvez structurer différemment votre méthode :

   No_Ident:=Num(Demander("Numéro d'identification"))  `No_Ident est de type Numérique
   Si(Ok=1)
      CHERCHER([Personnes]Id=No_Ident)
   Fin de si

Déclarer deux fois la même variable par deux directives de compilation différentes constitue, bien sûr, un retypage. Si, dans la même base, vous écrivez :

   C_BOOLEEN(LaVariable)
   C_TEXTE(LaVariable)

le compilateur est confronté à un dilemme et vous demande quelles étaient vos intentions. Le remède est simple : renommez l'une des deux variables.

Il ne faut pas oublier que le conflit de types pour une directive C_ALPHA peut surgir si vous modifiez la longueur maximale de la chaîne de caractères. Ainsi, si vous écrivez :

   C_ALPHA(5;MaChaine)
   MaChaine:="Fleur"
   C_ALPHA(7;MaChaine)
   MaChaine:="Bonjour"

le compilateur est dans une situation de conflit puisque dans la déclaration des variables de type Alphanumérique, il doit réserver un emplacement de taille adéquate.

Dans ce cas, le remède consiste à donner une directive de compilation qui prenne la longueur maximale, puisque par défaut, le compilateur acceptera une longueur inférieure. Vous pouvez donc écrire :

   C_ALPHA(7;LaChaine)
   LaChaine:="Fleur"
   LaChaine:="Bonjour"

Note : Si vous aviez écrit deux fois C_ALPHA(7;LaChaine), c'est-à-dire :

   C_ALPHA(7;LaChaine)
   LaChaine:="Fleur"
   C_ALPHA(7;LaChaine)
   LaChaine:="Bonjour"

le compilateur l'accepterait tout à fait. C'est simplement redondant.

Les conflits de types pour les variables locales sont absolument identiques aux conflits de types pour les variables process et interprocess, à ceci près que ces conflits se déroulent dans un espace plus restreint.

Les conflits se jouent au niveau général de la base pour les variables process et interprocess. Les conflits se jouent au niveau particulier de la méthode pour les variables locales. Vous ne pouvez donc pas écrire dans la même méthode :

   $Temp:="Bonjour" 

et puis plus loin

   $Temp:=5

En revanche, vous pouvez écrire dans une méthode M1 :

   $Temp:="Bonjour"

et dans une méthode M2 :

   $Temp:=5

Les conflits possibles pour un tableau ne portent jamais sur la taille du tableau. En mode compilé comme en mode interprété, les tableaux sont gérés dynamiquement. La taille d'un tableau peut varier au fil des méthodes et vous n'avez pas, bien sûr, à déclarer une taille maximale pour un tableau.

Vous pouvez, en conséquence, dimensionner un tableau à zéro, ajouter ou retirer des éléments, en effacer le contenu. Dans l'optique de la compilation, et ce, dans une même méthode, pour un tableau local ou dans toute la base pour un tableau process ou interprocess, vous devez veiller aux points suivants :

• ne pas changer le type des éléments du tableau,

• ne pas changer le nombre de dimensions d'un tableau,

• dans le cas des tableaux Alpha, ne pas changer la longueur des chaînes de caractères.

Si vous déclarez un tableau comme étant un tableau d'Entiers, il doit rester un tableau d'Entiers pour toute la base. Il ne pourra jamais contenir, par exemple, des éléments de type Booléen.

Si, dans une application, vous écrivez :

   TABLEAU ENTIER(LeTableau;5)
   TABLEAU BOOLEEN(LeTableau;5)

le compilateur ne peut identifier pour vous le type de LeTableau.

Renommez simplement l'un des deux tableaux.

En version interprétée, il peut vous arriver de changer le nombre de dimensions d'un tableau.

Lorsque le compilateur établit sa table des symboles, il gère différemment les tableaux à une dimension et les tableaux à deux dimensions.

En conséquence, un tableau déclaré une fois comme étant un tableau à une dimension ne peut être re-déclaré ou utilisé comme un tableau à deux dimensions et vice versa.

Dans une même base, vous ne pouvez donc pas avoir :

   TABLEAU ENTIER(LeTableau1;10)
   TABLEAU ENTIER(LeTableau1;10;10)

En revanche, vous pouvez, évidemment, avoir dans la même application

   TABLEAU ENTIER(LeTableau1;10)
   TABLEAU ENTIER(LeTableau2;10;10)

Par ailleurs, vous pouvez parfaitement écrire :

   TABLEAU BOOLEEN(LeTableau;5)
   TABLEAU BOOLEEN(LeTableau;10)

Comme vous pouvez le noter dans nos exemples, c'est le nombre de dimensions d'un tableau qu'on ne peut changer en cours d'application et non la valeur des dimensions du tableau.

Note : Un tableau à deux dimensions est en fait un ensemble de plusieurs tableaux à une dimension. Pour plus de précisions, reportez-vous à la section Tableaux à deux dimensions.

Les tableaux de chaînes fixes, aussi appelés tableaux Alpha, suivent la même règle que les variables Alphanumériques et pour les mêmes raisons.

Si vous écrivez :

   TABLEAU ALPHA(5;LeTableau;10)
   TABLEAU ALPHA(10;LeTableau;10)

le compilateur détecte un conflit de longueur. Le remède est simple : comme dans les chaînes Alpha, vous déclarez la longueur maximale. Le compilateur gère automatiquement les longueurs inférieures.

Lors de l'utilisation des commandes COPIER TABLEAU, ENUMERATION VERS TABLEAU, TABLEAU VERS ENUMERATION, SELECTION VERS TABLEAU, SELECTION LIMITEE VERS TABLEAU, TABLEAU VERS SELECTION, VALEURS DISTINCTES, vous pouvez, volontairement ou involontairement, être conduit à des changements de type d'éléments ou de nombre de dimensions, ou pour un tableau Alpha, à des changements de longueur de chaîne. Vous vous retrouverez donc dans un des trois cas cités précédemment.

Le compilateur vous délivrera un message d'erreur et la correction que vous aurez à faire sera en général évidente. Des exemples de retypage implicite de tableaux sont fournis dans la section Précisions de syntaxe.

Si vous souhaitez compiler une base de données qui utilise des tableaux locaux (tableaux visibles uniquement par les méthodes qui les ont créés), il est nécessaire de les déclarer explicitement dans 4D avant de les utiliser.

La déclaration explicite d'un tableau signifie l'utilisation d'une commande de type TABLEAU REEL, TABLEAU ENTIER, etc.

Par exemple, si une méthode génère un tableau local d'entiers contenant 10 valeurs, vous devez écrire au préalable la ligne suivante :

   TABLEAU ENTIER($MonTableau;10)

Les variables dessinées dans un formulaire, qu'il s'agisse d'une case à cocher ou d'une zone externe, sont toutes des variables soit process, soit interprocess.

En mode interprété, la question des types de ces variables ne se pose pas dans la pratique. Elle peut se poser, en revanche, dans l'optique d'une application compilée. Les règles du jeu sont cependant transparentes :

• soit vous avez typé votre variable,

• soit le compilateur lui attribue un type par défaut qui peut être défini dans les Préférences de compilation (voir le manuel Mode Structure).

Les variables suivantes sont considérées comme des Numériques par défaut :

Case à cocher

Case a cocher 3D

Bouton

Bouton inversé

Bouton invisible

Bouton 3D

Bouton image

Grille de boutons

Bouton radio

Bouton radio 3D

Radio image

Menu image

Menu déroulant hiérarchique

Liste hiérarchique

Règle

Cadran

Thermomètre

Note : Les variables de type Règle, Cadran et Thermomètre seront toujours typées comme des Numériques, même si vous avez choisi l'option Entier long par défaut pour le type des boutons dans les Préférences.

Pour ces variables, vous ne pouvez jamais vous trouver dans un conflit de types puisqu'elles ne peuvent avoir d'autres types que ce type-là, qu'on soit en interprété ou en compilé.

Les seuls conflits de types possibles sur l'une de ces variables viendraient du fait que le nom d'une variable serait le même que celui d'une autre variable placée à un autre endroit dans l'application. Dans ce cas, le remède consiste à renommer cette deuxième variable.

Une zone de graphe a automatiquement le type Graphe (Entier long). Il ne peut jamais y avoir de conflit de type.

Les seuls conflits de type possibles sur une variable de type Graphe viendraient du fait que le nom de cette variable serait le même que celui d'une autre variable placée à un autre endroit dans l'application. Dans ce cas, le remède consiste à renommer cette deuxième variable.

Une zone externe est toujours un Entier long. Il ne peut jamais y avoir de conflit de types.

Les seuls conflits de types possibles sur une variable Zone externe viendraient du fait que le nom de cette variable serait le même que celui d'une autre variable placée à un autre endroit dans l'application. Dans ce cas, le remède consiste à renommer cette deuxième variable.

Ces variables sont les suivantes :

Variable non-saisissable,

Variable saisissable,

Liste déroulante,

Menu/liste déroulante,

Zone de défilement,

Combo box,

Pop-up Menu,

Onglet.

Ces variables se divisent en deux catégories :

• les variables simples (variables saisissables et variables non-saisissables),

• les variables d'affichage de tableaux (listes déroulantes, menus/listes déroulantes, zone de défilement, pop-up menu, combo box, onglets).

• Variables simples

Par défaut, ces variables reçoivent le type Texte. Si elles sont utilisées dans une méthode objet ou une méthode formulaire, c'est le type que vous avez choisi qui leur sera attribué.

Vous n'avez aucun risque de conflit de types autre que celui qui serait généré par une attribution préalable du même nom à une autre variable.

• Variables d'affichage de tableaux

De nombreuses variables vous servent à afficher des tableaux dans les formulaires. Si les valeurs par défaut ont été saisies au niveau des contrôles de saisie des variables en mode structure, il est conseillé de typer les variables correspondantes explicitement par une déclaration de type tableau (TABLEAU ALPHA, TABLEAU TEXTE...).

Si vous utilisez des pointeurs dans vos applications, vous avez pu profiter de la puissance et de la flexibilité de cet outil dans 4e Dimension. Le compilateur en conserve intégralement les avantages.

Un pointeur peut pointer indifféremment sur une table, une variable ou un champ. Un même pointeur peut pointer sur des variables de type différent : veillez à ne pas générer des conflits artificiellement, en attribuant à une même variable des types différents.

Faites simplement attention à ne pas changer en cours de route le type de la variable sur laquelle pointe le pointeur en faisant, par exemple, une manipulation du type suivant :

   LaVariable:=5,3
   LePointeur:=-> LaVariable 
   LePointeur->:=6,4
   LePointeur->:=Faux

Dans ce cas de figure, votre pointeur dépointé est une variable Numérique. En affectant à cette variable une valeur booléenne, vous provoquez un conflit de types.

Si vous avez besoin dans une même méthode d'utiliser les pointeurs pour des propos différents, prenez soin de définir votre pointeur :

   LaVariable:=5,3
   LePointeur:=-> LaVariable 
   LePointeur->:=6,4
   LeBool:=Vrai
   LePointeur:=->LeBool
   LePointeur->:=Faux

Un pointeur n'a aucune existence propre. Il est toujours défini en fonction de l'objet qu'il représente. C'est pourquoi le compilateur ne peut pas détecter des conflits de types générés par une utilisation sans contrôle des pointeurs. Vous n'aurez donc pas, en cas de conflit, de message d'erreur durant la phase de typage ou celle de compilation.

Cela ne veut pas dire que lorsque vous utilisez des pointeurs, vous travaillez sans filet. Le compilateur peut vérifier vos utilisations de pointeurs lorsque vous cochez l'option Contrôle d'exécution dans les Préférences de compilation (cf. manuel Mode Structure).

Le compilateur a besoin, au moment de la compilation, des définitions des commandes des plug-ins utilisées dans la base à compiler, c'est-à-dire du nombre et du type des paramètres de ces commandes. Les risques d'erreur de typage sont inexistants à partir du moment où le compilateur trouve effectivement dans l'application ce que vous avez déclaré.

Assurez-vous que vos plug-ins sont installés dans le dossier PlugIns, à l'un des emplacements autorisés par 4e Dimension : à côté du fichier de structure de la base ou à côté de l'application exécutable (Windows) / dans le progiciel (Mac OS). Pour des raisons de compatibilité, il reste possible d'utiliser un dossier Win4DX ou Mac4DX à côté du fichier de structure. Pour plus d'informations, reportez-vous au Guide d'installation de 4e Dimension.

Le compilateur ne duplique pas le fichier mais tient compte des déclarations des commandes sans rien vous demander en supplément.

Si vos plug-ins sont placés ailleurs, le compilateur vous demande de les localiser lors du typage, via une boîte de dialogue d'ouverture de documents.

Certains plug-ins, par exemple 4D Write, utilisent des commandes qui provoquent l'appel implicite à des commandes 4e Dimension.

Prenons un exemple avec 4D Write. Vous disposez d'une commande appelée WR APPELER SUR EVENEMENT. La syntaxe de cette commande est :

Le dernier paramètre que vous passez à cette routine est le nom d'une méthode, que vous aurez vous-même écrite dans 4e Dimension. Cette méthode sera appelée par 4D Write chaque fois que l'événement attendu sera reçu et cette méthode recevra automatiquement les paramètres suivants :

Afin que le compilateur connaisse l'existence de ces paramètres et les prenne en compte, vous devez vous assurer qu'ils peuvent effectivement être typés, soit par une directive de compilation, soit parce que leur utilisation, suffisamment explicite, permet de déduire leur type.

4e Dimension et 4D Insider permettent de créer et de manipuler des composants 4D. Les composants s'apparentent à des librairies d'objets, dans lesquelles chaque objet dispose d'un attribut ("Privé", "Protégé" ou "Public") indiquant s'il sera visible, modifiable, etc. Pour plus d'informations sur la gestion des composants 4D, reportez-vous à la documentation de 4D Insider.

En principe, le développeur de composants 4D doit s'assurer que le composant est compilable et ne risque pas de générer de conflits. Cette possibilité ne peut toutefois être totalement exclue. En cas d'erreur de compilation provoquée par un objet appartenant à un composant, le compilateur affichera les informations suivantes, en fonction de l'attribut de l'objet :

• "Privé" : le compilateur ne fournit pas le nom de l'objet en cause, mais celui du composant 4D.

• "Protégé" ou "Public" : le compilateur désigne l'objet en cause, comme pour tout autre objet de la base (fonctionnement standard).

Manipulation des locales $0…$N et passation des paramètres

Les manipulations des variables locales suivent toutes les règles déjà énoncées. De même que toutes les autres variables, elles ne peuvent être retypées en cours de méthode.

Dans ce paragraphe, nous abordons deux cas de figure où l'inattention pourrait conduire à des conflits de types :

• Lorsque vous avez en fait besoin d'un retypage. L'utilisation de pointeurs vous permet alors d'éviter les conflits de types.

• Lorsque vous avez besoin d'adresser des paramètres par indirection.

Il n'est pas possible de retyper une variable. Il est, en revanche, tout à fait possible de faire pointer un pointeur successivement sur des variables de type différent.

Un exemple nous permet d'illustrer ce propos : écrivons une fonction qui nous renvoie l'occupation mémoire d'un tableau à une dimension suivant son type. Le résultat est un numérique dans tous les cas sauf deux : dans le cas des tableaux Texte et des tableaux Image, la taille mémoire occupée par le tableau dépend de valeurs inexprimables sous forme numérique (cf. section Tableaux et mémoire).

Dans le cas des tableaux Texte et des tableaux Image, nous renverrons comme résultat une chaîne de caractères. Cette fonction requiert un paramètre : un pointeur sur le tableau dont on veut connaître l'occupation mémoire.

Pour effectuer cette opération, vous avez le choix entre deux méthodes :

• ne travailler qu'avec des variables locales et ne pas vous soucier de leur type — mais dans ce cas, la méthode ne fonctionnera qu'en mode interprété.

• utiliser des pointeurs et alors travailler indifféremment en interprété et en compilé.

• Fonction OccupMém en interprété seulement (exemple pour Macintosh)

   $Taille:=Taille tableau($1->)
   $Type:=Type($1->)
   Au cas ou
      :($Type=Est un tableau numérique)
         $0:=8+($Taille*10)   ` $0 est un Numérique
      :($Type=Est un tableau entier)
         $0:=8+($Taille*2)   
      :($Type=Est un tableau entierlong)
         $0:=8+($Taille*4)   
      :($Type=Est un tableau date)
         $0:=8+($Taille*6)
      :($Type=Est un tableau texte)
         $0:=Chaine(8+($Taille*4))+("+Somme des longueurs des textes")   ` $0 est un Texte
      :($Type=Est un tableau image)
         $0:=Chaine(8+($Taille*4))+("+Somme des tailles des images")   ` $0 est un Texte
      :($Type=Est un tableau pointeur)
         $0:=8+($Taille*16)   
      :($Type=Est un tableau booléen)
         $0:=8+($Taille/8)   
   Fin de cas

Dans la méthode ci-dessus, il y a changement de type de $0 suivant les valeurs de $1.

• Fonction OccupMém en mode interprété et compilé (exemple pour Macintosh)

Ecrivons maintenant cette méthode en utilisant un pointeur :

   $Taille:=Taille tableau($1->)
   $Type:=Type($1->)
   VarNum:=0
   Au cas ou
      :($Type=Est un tableau numérique)
         VarNum:=8+($Taille*10)   ` VarNum est un Numérique
      :($Type=Est un tableau entier)
         VarNum:=8+($Taille*2)   
      :($Type=Est un tableau entierlong)
         VarNum:=8+($Taille*4)   
      :($Type=Est un tableau date)
         VarNum:=8+($Taille*6)   
      :($Type=Est un tableau texte)
         VarText:=Chaine(8+($Taille*4))+("+Somme des longueurs des textes")  
      :($Type=Est un tableau image)
         VarText:=Chaine(8+($Taille*4))+("+Somme des tailles des images")
      :($Type=Est un tableau pointeur)
         VarNum:=8+($Taille*16)   
      :($Type=Est un tableau booléen)
         VarNum:=8+($Taille/8)   
   Fin de cas
   Si (VarNum#0)
      $0:=->VarNum
   Sinon
      $0:=->VarText
   Fin de si

Il faut noter la différence entre ces deux séquences :

• dans le premier cas, le résultat de la fonction est la variable que l'on attendait,

• dans le second cas, le résultat de la fonction est un pointeur sur cette variable. Il vous appartient alors de simplement dépointer le résultat reçu.

Le compilateur gère la puissance et la souplesse de l'indirection sur les paramètres. En mode interprété, 4e Dimension vous donne toute latitude concernant le nombre et le type des paramètres. Vous gardez en mode compilé cette même liberté à condition de ne pas introduire de conflit de types et de ne pas utiliser, dans la méthode appelée, plus de paramètres que vous en avez passés, ce qui est facile.

Afin de contourner un éventuel conflit, les paramètres adressés par indirection doivent tous être du même type.

Pour une bonne gestion de cette indirection, il est important de respecter la convention suivante : si tous les paramètres ne sont pas adressés par indirection, ce qui est le cas le plus fréquent, il faut que les paramètres adressés par indirection soient passés en fin de liste.

A l'intérieur de la méthode, l'adressage par indirection se fait sous la forme : ${$i}, $i étant une variable numérique. ${$i} est appelé paramètre générique.

Illustrons notre propos par un exemple : écrivons une fonction qui prend des valeurs, fait leur somme et renvoie cette somme formatée suivant un format qui peut varier avec les valeurs.

A chaque appel à cette méthode, le nombre de valeurs à additionner peut varier. Il faudra donc passer comme paramètre à notre méthode les valeurs, en nombre variable, et le format, exprimé sous forme d'une chaîne de caractères.

Un appel à cette fonction se fera de la façon suivante :

   Résultat:=LaSomme("##0,00";125,2;33,5;24)

La méthode appelante récupérera dans ce cas la chaîne : 182,70, somme des nombres passés, formatée suivant le format spécifié. D'après ce que l'on a vu plus haut, les paramètres de la fonction doivent être passés dans un ordre précis : le format d'abord et ensuite les valeurs, dont le nombre peut varier d'un appel à l'autre.

Examinons maintenant la fonction que nous appelons LaSomme :

   $Somme:=0
   Boucle($i;2;Nombre de parametres)
      $Somme:=$Somme+${$i}
   Fin de boucle
   $0:=Chaine($Somme;$1)

Cette fonction pourra être appelée de diverses manières :

   Résultat:=LaSomme("##0,00";125,2;33,5;24)
   Résultat:=LaSomme("000";1;18;4;23;17)

De même que pour les autres variables locales, la déclaration du paramètre générique par directive de compilation n'est pas obligatoire. Si elle est nécessaire (cas d'ambiguïté ou d'optimisation), elle se fait avec la syntaxe suivante :

   C_ENTIER(${4})

La commande ci-dessus signifie que tous les paramètres à partir du quatrième (inclus) seront adressés par indirection. Ils seront tous de type Entier. Les types de $1, $2 et $3 pourront être quelconques. En revanche, si vous utilisez $2 par indirection, le type utilisé sera le type générique. Il sera donc de type Entier, même si pour vous, par exemple, il était de type Réel.

Note : Le compilateur utilisant cette commande durant le typage, le nombre, dans la déclaration, doit toujours être une constante et jamais une variable.

Des variables et des constantes de 4e Dimension ont un type et une identité fixés par le compilateur. On ne peut donc créer une nouvelle variable, une méthode, une fonction ou une commande de plug-in portant le nom d'une de ces variables ou d'une de ces constantes. Bien entendu, vous pouvez tester leur valeur et les utiliser comme auparavant.

Voici la liste complète des Variables système de 4e Dimension accompagnées de leur type.

Lorsqu'on crée une colonne calculée dans un état, 4e Dimension crée automatiquement une variable C1 pour la première, C2, C3... pour les autres. Généralement, cette création est faite de façon transparente pour vous.

Dans le cas où vous utiliseriez ces variables dans des méthodes, souvenez-vous que, comme les autres variables, les variables C1, C2... ne peuvent être retypées.

La liste des constantes prédéfinies de 4e Dimension peut être consultée dans ce manuel, vous pouvez également les visualiser dans l'Explorateur, en mode Structure.

Conseils d'optimisation, Messages d'erreurs, Précisions de syntaxe, Utilisation des directives de compilation.