Compilateur et Variable()

Je viens de relire les avancés du compilateur et...un problème va se poser.
La commande Variable() qui renvoie l' existence ou non d' une variable
ne fonctionnera pas avec.
Donc plus de :

if variable("ma_variable$")=0 then dim ma_variable$

dans les subs.

Il va donc falloir trouver un palliatif, un bout de code magique pour remplacer cette commande.
Quelqu' un a t il un début d' idée (en dehors de toutes les déclarer au début   )?


Edit : un début de piste pour moi serait un tableau Var$(...) avec tous les noms de variables et une verif dans ce tableau.
Qu' en pensez vous ?

A mon humble avis, tester l’existence ou non d’une variable n’a pas un grand intérêt.
Si la variable est locale à la sub, il n’y a pas de problème : on la déclare par DIM_LOCAL.
Si la variable est globale, pourquoi ne pas la déclarer en dehors de la sub dans le bloc de déclaration ? Ça serait plus logique, non ?
D’ailleurs, entre cette déclaration dans une SUB pouvant se répéter pour d’autres SUB  

Code:

IF VARIABLE("hello") = 0 THEN DIM hello

et la seule déclaration au bloc des déclaration

Code:

DIM hello

laquelle est la plus concise ?

D’un autre côté ne pas déclarer des variables globales dans une SUB, rend cette dernière entièrement indépendante du programme qui l’utilise. Vive l’indépendance !


Mais le débat est ouvert : les autres opinions sont les bienvenues.

Cela était bien pratique pour les "procédure-fonction" qui déclarait leurs propre variables de retours.

Il me semble que le problème n'en ai pas tout à fait un. Car il y aura un message d'erreur si une variable globale n'est pas déclarée par DIM ou si elle est déclarée 2 fois.
Donc en cours de codage il y aura immédiatement une alerte.

A+

je me suis fait une petite sub pour vérifier si une variable est déclaré ou pas.
cela oblige à une petite gymnastique, il faut ajouter chaque variable déclaré
à une chaine var$.

Code:

dim var$,retour$
var$="var$,retour$,"

verif_var("var$")
end

sub verif_var(V$)
  dim_local a$,L$,sep%,b%,x% ,retour%
  L$=var$
  for x%=1 to len(L$)
      a$=left$(L$,1)
      if a$=",":b%=b%+1:end_if
      if len(L$)>1 :L$=right$(L$,len(L$)-1):end_if
  next x%
  L$=var$
  while b%<>0
      sep%=instr(L$,",")
      a$=left$(L$,sep%-1)
      if a$=V$ : retour%=1:exit_while:end_if
      if len(L$)>sep% :L$=right$(L$,len(L$)-sep%):end_if
      b%=b%-1
  end_while
  if retour%=1 : message "La variable :"+chr$(13)+V$+chr$(13)+"est déjà déclaré !" : end_if
end_sub

@ jean claude,

Je ne sais pas ce que prévoit Jack pour cela, un petit message de l' éditeur serait le bienvenu c' est sûr.

Toute cette gymnastique cérébrale Ygeronimienne est belle puisqu’elle entretient nos neurones.
Mais la concision et la clarté Papydallienne peuvent aussi être défendues.

Code:

DIM var$

Point final : on est certain que la variable var$ est bien déclarée.
C’est plus concis, plus claire ; ça facilite la maintenance de notre programme et on reste toujours maître de ce qu’on fait.
Suis-je passé à côté d’autre chose que je n’ai pas saisie ?

Ce qui serait vraiment beau c’est l’implémentation de fonction (par exemple : FNC(…)) à l’instar de SUB(…)
Dans ce cas la fonction retourne une valeur dans son nom et on ne se soucie pas de déclarer une variable de retour.

Vains dieux...

Nous allons assister au match entre Papydaliens et Ygeronimiens...
Deux théories s'affontent de vant la foule (?) ébaubie des Panoramiciens...

Nul doute qu'il n'en peut sortir que du positif

Perso, je n'entre pas dans le débat et voilà mes raisons:
Pour ma la version "compilée" sera jeune plus ou moins bugguée (potentiellement, je me doute que Jack aura fait une tonne de tests et retiré beaucoup des petites bêtes nuisibles mais il en restera probablement qui seront trouvés). Je me dis que la version évoluera ensuite quand il ne restera plus de bestioles dedans et qu'à ce moment là, on aura sans doute une solution pour gérer la déclaration des variables (ou alors, ce sera pour moi le moment où l'on pourra dire à Jack qu'il manque une solution pour ce problème)

Je pars du principe que nos sources ne seront pas portables directement dans la version compilable et devront donc être revue en fonction des indications de Jack.

@ Papydall,

Présenté comme je l' ai fait plus haut la procédure n' a aucun sens je te l' accorde.
Mais sur un programme de plusieurs centaines de lignes voir plusieurs fichiers ".bas" en #include
fait en plusieurs étapes (jours) il suffit de faire appel à la sub pour savoir si on l' a déjà utilisé ou pas.

Je poursuivrai en te disant que la fameuse ligne (dans un cas comme je te le décris plus haut):

if variable("ma_variable$")=0 then dim ma_variable$

a un effet pervers.
Si la variable est déjà quelque part, on n' est pas prévenu et on risque de lui attribuer une valeur parasite.

Message de Jack du 31 août.

Le compilateur avance à petit pas.

Il est basé sur PANORAMIC V 0.9.24 du 28 mars 2013, dont il reproduit les fonctionnalités... et les bugs ...

Une version alpha sera disponible dans un mois maximum.

Un peu de patience donc !!

Nous sommes tous impatients, mais ons ne peut être que impatients.

Jack fais très certainement ce qu'il peut et peut-être pas ce qu'il voudrait.

A+

Le debuggage doit être une horreur à faire. Perso moi, je préfère ne pas trop lui mettre la pression. S'il galère déjà sur des problèmes, je pense que ça le fait déjà assez suer de ne pas avancer aussi vite qu'il le voudrait.

Je dirai même plus, patience...