Directives Private_ON et Private_OFF

Encore une petite suggestion pour faciliter l'utilisation des INCLUDE, en vue de les utiliser pour inclure des sous-programmes standard, réutilisés un peu partout dans plusieurs programmes. Ce qui gêne, c'est la visibilité globale des variables, sans distinction.

Pourrait-on imaginer une paire de directives du type

Dim variable_globale_habituelle
...
Private_ON
Dim variable_locale valable jusqu'au Private_OFF
...
Private_OFF
...

On pourrait alors avoir une variable i% définie globalement au début du programme, et une variable différente i% définie et valable uniquement entre les deux directives Private_ON et Private_OFF.

Est-ce que cette idée est aberrante ou trop lourde à implémenter par rapport à la structure de Panoramic ?

Avec mes excuses si j'enfonce des portes ouvertes ou si cela paraît démésuré...

Pourquoi pas.
Mais il faudra bien faire attention aux GOTO:

si je suis ton raisonnement et que je fais:

Code:

dim a
label suite
private_on
dim a
a=2
goto suite
private_off
suite:
print a

je pense que beaucoup vont se demander pourquoi il s'affiche 0 et non pas 2.

Effectivement. Mais le but de cette suggestion était ailleurs. Imaginons un programme dans lequel un fait un INCLUDE contenant un sousprogramme réutilisé souvant. On aurait alors:

label test_code
dim i%, mauvais_code%
...
for i%=1 to 20
....
code% = text$(i%)
gosub test_code
if mauvais_code%=1
....
end_if
....
next i%
...
#INCLUDE "test_code.bas"
...


et test_code.bas contient:
Private_ON
dim i%
...
for i%=1 to 300
...
if code%=codes_valides(i%)
mauvais_code% = 0
return
end_if
next i%
mauvais_code%=1
return
Private_OFF


Le but étant d'éviter la lourdeur de construire des noms de variables à rallonge pour les variables locales d'un sous-programme, ce qui actuellement est indispensable pour éviter des conflits en faisant des INCLUDE voir même des copier/coller d'un sousprogramme dans d'autres programmes, ou d'avoir à reprendre toutes les variables.

Pour exemple, tu peux regarder mes routines de manipulation de dates et de détermination du jour de la semaine, où j'ai appliqué systématiquement cette technique pour rendre les variables indépendentes, mais c'est lourd à manipuler...

Je suis d'accord avec Klaus pour la lourdeur de la gestion de variables communes dans le cas d'include.
Et je rappelle que dans le vieux QBasic, les SUB avaient leurs variables locales (sauf directives SHARE, pratiques aussi), ce qui était bien pratique pour monter des collections de sous-programmes, les seules variables communes étant les paramètres à passer et à récupérer.

Autre chose, qui figure peut-être dans le manuel mais je n'ai pas vu: est-ce qu'une variable avec le suffixe % (i%) comme fait Klaus, et moi parfois, est bien traitée comme une variable entière, ou bien ça ne change rien ?

Edit: ma dernière question était idiote, il suffisait d'essayer:

Code:

dim i%, a
a = 1.234
print a
i% = 1.234
print i%
end

dans le dernier cas il s'affiche bien 1 tout seul.

Bonsoir
C'est une idée comme une autre, mais je viens de penser à des variables de transfert:

Code:

' essai de variable de transfert
dim transfer_a,transfer_b,transfer_c,transfer_d
dim transfer_a%,transfer_b%,transfer_c%,transfer_d%
dim transfer_a$,transfer_b$,transfer_c$,transfer_d$

dim a%,b%,c% ,a$
label essai
' -----------------
width 0,350:height 0,400:left 0,600:top 0,150
memo 1:width 1,300:height 1,100
memo 2:width 2,300:height 2,100:top 2,110
memo 3:width 3,300:height 3,100:top 3,220

a$="variable avant modification"
a%=10
b%=a%*2
c%=a%+b%

print_target_is 1
print a$:print "a%=",a%
print "b%=",b%
print "c%=",c%
' ------------
gosub essai
' ------------
print_target_is 3
print "retour des variables comme avant"
print a$:print "a%=",a%
print "b%=",b%
print "c%=",c%

end
' ==========================
essai:
  transfer_a$=a$
  transfer_a%=a%
  transfer_b%=b%
  transfer_c%=c%
 
  a$="variable mis en mémoire"+chr$(13)+"modification de celles-ci"
  a%=100
  b%=200
  c%=300
  print_target_is 2
  print a$:print "a%=",a%
  print "b%=",b%
  print "c%=",c%
  a$=transfer_a$
  a%=transfer_a%
  b%=transfer_b%
  c%=transfer_c%
return

Oui, techniquement, c'est une solution pour préserver une variable tout en réutilisant la même variable à l'ntérieur d'un sous-programme. Mais tu conviendras avec moi que d'une, c'est lour à mettre en oeuvre, et de deux, dans le cas des modules réutilisés avec INCLUDE, tu ne peux PAS savoir dans le module à inclure si une variable que tu veux utiliser a été définie à l'extérieur. Si tel n'est pas le cas, une erreur se produira sur variable indéfinie. Et s'il y a un certain nombre de variables comme ça, cela devient vite ingérable.

En réalité, tu as mis au point un mécanisme qui ressemble à une "pile" (un stack en anglais), sur laquelle on sauvegarde la valeur de la variable. Une directive du type PRIVATE_ON...PRIVATE_OFF pourrait automatiser ce processus, non pas au niveau des valeurs, mais au niveau des définitions et allocations mémoire ce ces variables - enfin, sur le plan technique interne à Panoramic, ce n'est pas à moi desuggérer ma meilleure implémentation...

En tout cas pour moi, l'objectif est de permettre la réutilisation d'un ensemble de modules contenant en général des sourprogrammes de service, à inclure par INCLUDE dans différents programmes d'application. Et même comme ça, étant donné que l'on ne peut pas passer de paramètres à un sous-programme, chaque sous-programme doit en faait être composé de deux fichiers physiquement distincts à include: le premier contenant

label nom_du_sousprogramme
dim toutes_les_variables_servant_de_paramètres

qui est à inclure au début du programme principal, et l'autre contenant:

nom_du_doudprogramme:
Private_ON
dim toutes_les_variables_locales
....
Private_OFF
return

qui est à ajouter à la fin du programme principal. C'est déjà assez compliqué à gérer; un soutien automatisé, quel qu'il soit d'ailleurs, pour gérer les variables privées ou locales serait d'un grand secours.

Moi je ne fais que donner une simple idée. Mais avec le programme que je suis en train de faire, cette technique ne me pose pas de problème, vu que je fais tout comme une bibliothèque, et que je regarde tel programme à ma convenance, avec les outils pour modifier les variables, contrôler les doublons etc... En faites, je n'ai pas l'intention de me servir de include, qui n'est pas visible. Il faut l'ouvrir dans un autre éditeur pour travailler dessus. Je fais la même chose, mais je peux gérer. J'ai pas d'apriori contre ta technique, elle est adapté à l'éditeur. Un programme, c'est d'abord une idée, qui est lié à ses habitudes, son adaptation à changer. Le programme, je l'ai commencé àprès ton refus de faire un éditeur (et qui n'est en aucun cas une critique. Je ne donne pas d'ordre), et avant que Jack ne dise qu'il allait sortir plutôt que prévu l'instruction include. Et dans mon cas cela me pose plus de problème, que de suivre mon idée. J'ai une liste de tout programme que je veux inclure, et chacun d'eux est visible à la demande. Ensuite à la fin le programme fera la compilation de tout cela dans l'ordre des chose, et avec le contrôle. Je serais seulement obligé d'ouvrir le programme généré avec l'éditeur classique, mais est-ce un problème?. Seulement il y a encore du boulot.

Pour le cas de Include, c'est justement pour y mettre des bouts de code qu'on n'a pas besoin de voir. Si tu veux que ce soit visible, ça ne sert évidemment à rien !
Un exemple: j'ai un sous-programme qui en fonction d'un nom de fichier image me rend sa largeur et sa hauteur. Je lui passe simplement le nom du fichier et je récupère en sortie les deux données, je me fiche de savoir comment il a fait puisque ça a été mis au point une fois pour toutes.
En tout cas c'est comme ça que je vois l'utilisation de Include.

Quant aux variables, je pense qu'il n'y a pas de solution simple, tout ce que vous dites me semble bien lourd à gérer, il me semble que que c'est plutôt un problème pour Jack. Sinon, si chacun fait ce qu'il veut (ce qu'il peut) à son idée dans son coin, ce ne sera pas universel et on ne pourra pas réutiliser les bibliothèques des autres.

Je suis d'accord sur le fait que chacun a sa méthode et sa conception, c'est un choix de liberté et cela permet à chacun de résoudre ses problèmes.
Je pense qui faut pour chacun avoir clairement une méthode dès le départ, et s'y tenir pour que son projet d'inclusion fonctionne. Pour ma part toutes les variables simples à une lettre sont considérées comme pouvant être utilisé dans tout programme sans que cela ne puisse interférer dans un autre (également. Si cela peut devenir le cas, il y aura transfert, comme dit Klaus une pile, qui se dépile pour reprendre sa variable, mais normalement sur cette logique, c'est une erreur d'avoir une variable simple qui puisse influencer un programme. Quant au reste, c'est chacun pour soi. Pour répondre pour mon cas où je donnais une petite base de mon programme, de fait d'avoir des onglet pour jeter un oeil sur un include, ne me gène pas dans mon programme, vu que recliquant sur celui du programme, celui-là disparait. Je ne vais pas rentrer dans les détails, mais il y a d'autre chose. Quant à l'histoire de transfert que j'ai pensé, c'est généralement le cas de quelques variables, parfois une seul, alors dire que cela alourdit considérablement la lisibilité d'un programme, il faut quant même relativiser. En réalité, cela concerne surtout les programmes qu'on a écrit précédemment, et le fait de les inclure à d'autre programme n'ont pas été vraiment pensé lors de la création. Si on a une directive générale, dès maintenant, l'inclusion des futurs programmes ne devraient pas poser problème. Chacun respect la méthode de l'autre. Il ne va pas y avoir quelqu'un qui dise aux autres, il faut faire comme ça, et se synchroniser sur la volonté d'un seul. On a tous des connaissances, une mémoire, un but, une compréhension différents, et chacun fait comme il peut, mais en parler peut donner une idée à un autre, sur une chose qu'il ne pensait pas, et peut-être, faire un meilleur choix dès le départ.
Je rajoute ceux-ci: il est claire que généralement dans un programme, on appel à un include, mas rarement un include faisant appel à un autre include. Donc à part xyz, la 1ère partie des voyelles simples peuvent être utilisé par le programme que l'on créé, et si on fait un programme qui deviendra ensuite appelé par un autre, on peut choisir l'autre moitié des variables pour les opérations ordinaires