Le manuel PureBasic définit les modules comme suit :
Les modules sont un moyen facile d'isoler une partie du code du code principal, ce qui permet de réutiliser et de partager le code sans risque de conflit de nom. Dans d'autres langages de programmation, les modules sont appelés `espaces de noms'.
Techniquement, les modules sont des mini-programmes dans le cadre de programmes plus vastes, que l'on pourrait appeler des procédures. Mais contrairement aux procédures, ils exécutent leur code immédiat sans que le programme parent ne les appelle. De plus, contrairement aux procédures, les modules pourraient aussi contenir leurs propres procédures.
Démontrons cela avec quelques exemples simples. Considérez cette procédure vide :
Le module équivalent de la procédure ci-dessus serait cet ensemble de fermetures :
Code : Tout sélectionner
DeclareModule monModule
EndDeclareModule
Module monModule
EndModule
À ce stade, ils ne font absolument rien. Donc, ajoutons une variable à la procédure :
Nous savons que la variable maVar n'est pas accessible depuis le programme parent, et essayer d'y accéder ne ferait que générer une nouvelle variable du même nom dans le programme parent, avec pour résultat une valeur zéro :
Code : Tout sélectionner
Procedure maProcedure()
Protected maVar = 123
EndProcedure
Debug maProcedure() ;== 123
Des trucs simples et basiques.
Dans le cas des modules, il y aurait deux façons d'ajouter des variables. C'est la première façon :
Code : Tout sélectionner
DeclareModule monModule
EndDeclareModule
Module monModule
Define maVar = 123
EndModule
Et ce serait la deuxième façon :
Code : Tout sélectionner
DeclareModule monModule
Define maVar = 123
EndDeclareModule
Module monModule
EndModule
Quelle est la différence ? Avant de répondre à cette question, jetons un autre coup d'œil à la structure de base du module :
Code : Tout sélectionner
DeclareModule monModule
EndDeclareModule
Module monModule
EndModule
Comme le nom de la fonction l'indique, la section supérieure DeclareModule gère les déclarations du module, tandis que la section inférieure du module abrite toutes ses fonctions. Cependant, tout le code de la section module resterait verrouillé et inaccessible au programme parent à moins qu'ils ne soient sélectivement et expressément déclarés dans la section de déclaration supérieure. Pour illustrer cela, revenons à l'exemple précédent de la variable.
Dans le premier des deux exemples de modules, la variable maVar a été déclarée dans la section inférieure du module :
Code : Tout sélectionner
DeclareModule monModule
EndDeclareModule
Module monModule
Define maVar = 123
EndModule
Comme la procédure précédente, les variables dans les modules ne sont pas accessibles à partir du programme parent, et essayer d'y accéder ne ferait que générer une nouvelle variable du même nom dans le programme parent, avec pour résultat une valeur zéro :
Code : Tout sélectionner
DeclareModule monModule
EndDeclareModule
Module monModule
Define maVar = 123
EndModule
Debug maVar ;== 0
Contrairement aux procédures, qui devraient retourner la valeur de la variable au programme parent, les variables des modules peuvent être référencées et accédées directement. La syntaxe pour le référencement des variables dans les modules du programme parent serait de les préfixer avec le nom du module, comme suit :
Code : Tout sélectionner
DeclareModule monModule
EndDeclareModule
Module monModule
Define maVar = 123
EndModule
Debug monModule::maVar ;== 0 ?
Cependant, vous remarquerez que la sortie résultante est toujours à zéro. Pourquoi cela ?
Comme indiqué précédemment, les variables et les fonctions contenues dans les modules ne sont pas accessibles par le programme parent à moins qu'elles ne soient expressément mises à disposition. Et cela se fait en les déclarant dans la section de déclaration supérieure de la structure du module.
Pour remédier à cela, et rendre la variable accessible, il faudrait utiliser la deuxième méthode, qui déclare la variable maVar, comme ça :
Code : Tout sélectionner
DeclareModule monModule
Define maVar = 123
EndDeclareModule
Module monModule
EndModule
Debug monModule::maVar ;== 123
De plus, les valeurs de ces variables publiques n'ont pas besoin d'être assignées dans la section déclarations, et pourraient également être assignées dans le corps du module, comme c'est le cas :
Code : Tout sélectionner
DeclareModule monModule
Define maVar
EndDeclareModule
Module monModule
maVar = 123
EndModule
Debug monModule::maVar ;== 123
Alors, que pouvons-nous faire d'autre avec les modules ?
Les procédures sont excellentes pour moduler les fonctions réutilisables, ce qui évite d'avoir besoin d'un code répétitif et fastidieux. Cependant, dans le meilleur des cas, chaque procédure ne peut exécuter qu'une poignée de processus. Considérez ceci :
Code : Tout sélectionner
Procedure maProcedure(a, b)
c = a + b
ProcedureReturn c
EndProcedure
Debug maProcedure(1, 2) ; == 3
L'équivalent module de la procédure ci-dessus ressemblerait à ceci :
Code : Tout sélectionner
DeclareModule monModule
Declare maProcedure(a, b))
EndDeclareModule
Module monModule
Procedure maProcedure(a, b)
c = a + b
ProcedureReturn c
EndProcedure
EndModule
Debug monModule::maProcedure(1, 2) ; == 3
Remarquez comment la même procédure a été ajoutée dans le module, et remarquez comment elle a également été déclarée dans la section supérieure de déclaration. Il est ensuite appelé dans la même méthode, en préfixant le nom du module au nom de la procédure.
Au fond, c'est tout ce qu'il y a aux modules. Une procédure glorifiée avec son propre espace de noms. Bien que c'est là que s'arrêtent les similitudes entre les procédures et les modules.
Microsoft Windows 10 Famille 64 bits : Carte mère : ASRock 970 Extreme3 R2.0 : Carte Graphique NVIDIA GeForce RTX 3080 : Processeur AMD FX 6300 6 cœurs 12 threads 3,50 GHz PB 5.73 PB 6.00 LTS (x64)
Un homme doit être poli, mais il doit aussi être libre !