Version instantanée du 12 septembre 2012 PANORAMIC V0.9.24i2

Nous pouvons déclarer des procédures avec SUB et bientôt des fonctions.
Ces 2 types de sous-programmes sont appelés par leur nom respectif. Il leur manque une commande fort utile à savoir la sortie prématurée du sous-programme selon certaines conditions.
Par exemple EXIT_SUB et EXIT_FUNCTION.
Pourquoi chercher à pouvoir déclarer des LABEL pour les appeler avec la plus mauvaise commande jamais inventée dans l’histoire de la programmation : j’ai nommé la commande GOTO.
Il est, me semble-t-il plus efficace , de disposer de EXIT_SUB.

J’ai débuté, comme la plus part d’ici, avec BASIC.
À cette époque les GOTO étaient une providence parce les instructions étaient numérotées et qu’on ne pouvait pas coder tout un bloc sur une même ligne.
Alors un goto par ci, un goto par là et le programme devient vite un véritable casse tête pour celui qui veut comprendre ou modifier quelque chose.
C’était l’époque qu’on qualifiait de « programmation sauvage ».
Juste après j’ai fait la découverte de la programmation structurée avec Turbo Pascal : et j’ai juré que je n’utiliserais jamais plus GOTO.

j’admets que dans des rares conditions on a besoin de faire un GOTO beaucoup plus simplement que de faire la gymnastique pour coder la même chose, mais je le répète c’est rare.
D’après ce que j’ai compris, GOTO restera supportée par Panoramic.

Dans mes posts précédents j’ai donné UNE méthode pour s’en sortir à défaut de EXIT_SUB.
Mais je ne soutiens pas les LABEL_LOCAL : c’est ma façon de voir.

Parfois je PROPOSE, jamais je n’IMPOSE.
Et Jack est son propre maître : il fait ce qu’il veut et ce qu’il peut et je ne peux qu’en être reconnaissant !

Vous parlez de sortir d'une procédure "sub xxx()...end_sub".
Mais, dans quel cas serait il nécessaire de sortir par un "Exit_Sub" ?
On a déjà "If...Else...End_if" pour ouvrir sur plusieurs voix ...non?...

@Papydall:
Sur le principe, je suis parfaitement d'accord avec toi. La commande GOTO avec ses labels associés, ce sont des fossiles d'un autre âge de la programmation.

Mais, en Panoramic, il y a actuellement besoin de labels pour 2 raisons:

1. tous les évènements car à ce jour, les commandes ON_xxx n'acceptent que les labels en simulant un GOSUB - il faut donc terminer par RETURN. C'est pourquoi j'ai suggéré à un autre endroit, la directive #ON_EVENT_PROCEDURE.

2. pour au moins une forme de GOTO, il n'y a pas de remplacement possible: c'est le ON_ERROR_GOTO. On ne peut même pas l'assimiler à un évènement et l'inclure dans la logique développée dans l'agrumentation citée ci-dessus, car le principe d'une procédure, c'est qu'au retour, cela continue en ligne comme après un GOSUB, mais ce n'est pas le cas d'un ON_ERROR_GOTO. Il faudrait développer une stratégie tout à fait différente et on sortirait de l'esprit du Basic si l'on faisait ce qu'on fait en Delphi avec TRY...FINALLY...END.

Et puisqu'il faut pouvoir au moins faire des labels pour les ON_ERROR_GOTO, il faut absolument la commande LABEL_LOCAL pour définit des labels locaux à une procédure, car sinon, on aura la plus grande confusion dès lors qu'on essayera d'inclure dans un même programme des procédures de provenances diverses.

Cependant, ceci est totalement indépendant de la notion de EXIT_SUB et EXIT_FUNCTION qui me parraissent tout aussi indispensables pour pouvoir produire des programmes élégants et lisibles. Sinon, il faut à nouveau recourir à des GOTO inutiles, ou à des variables locales servant d'indicateurs, avec une série de IF imbriqués pour conditionner le traitement.

Vous rendez-vous compte qu'en voulant supprimer les gotos, je ne pourrais plus programmer mes codes, comme celui-ci:

Code:

label a,b,c,d,e,f:font_size 0,16
dim a$
a$="Dites: "
gosub c
gosub c
print a$
end

' -----
a:
a$= a$ +"i"
goto d
' -----
e:
a$= a$ +"!"
goto f
' ----------
b:
a$= a$ +"o"
goto a
' ------
c:
a$=a$+"c"
goto b
' ------
d:
a$= a$ +"n"
goto e
' ------
f:
a$= a$ +" "
return

@Klaus
Nos point de vues ne sont pas divergents : j’ai disais que GOTO est utile dans des rares cas.
Tu en as donné une : ON_ERROR_GOTO.
Parfois, avec toute la bonne volonté du monde et la bonne structuration de l’algorithme, il est presqu’impossible de ne pas se servir de GOTO.
La vraie question n’est pas de bannir le binôme GOTO et LABEL, mais de prévoir le EXIT_SUB et le branchement aux SUB pour tous les ON_xxx.

@ygeronimi

Il y a des cas où la sortie provoquée d’une procédure est utile. C’est un peu comme EXIT_FOR, EXIT_WHILE, EXIT_REPEAT.
C’est aussi un peu comme dans un sous-programme appelé par GOSUB où l’on peut coder plusieurs RETURN

Voici un code où l’on peut mettre EXIT_SUB.
L’exemple choisis n’est pas dernier cri (je manque d’inspiration ces jours-ci) et les EXIT_SUB ne sont pas indispensables.
Mais, dans la procédure ‘transcode’, si m% = 1, n’est pas sortir de la procédure à cet endroit, fait que le programme continue de tester des choses impossibles avant de sortir normalement par END_SUB.

Code:

dim mois%, NomMois$
 saisie(mois%)
 transcode(mois%,NomMois$)
 print_locate 50,50 : print mois%; " c'est "; NomMois$

 end
SUB saisie(month%)
  DIM_LOCAL m$
  repeat
    repeat
      m$ = message_input$("ENTRER LE NUMERO DU MOIS","MOIS = ?","")
    until numeric(m$) = 1
    mois% = val(m$)
  until (mois% > 0) and (mois% < 13)
END_SUB

SUB transcode(m%,NameMonth$)
  if m% = 01 then NomMois$ = "JANVIER"    : ' EXIT_SUB
  if m% = 02 then NomMois$ = "FEVRIER"    : ' EXIT_SUB
  if m% = 03 then NomMois$ = "MARS"      : ' EXIT_SUB
  if m% = 04 then NomMois$ = "AVRIL"      : ' EXIT_SUB
  if m% = 05 then NomMois$ = "MAI"        : ' EXIT_SUB
  if m% = 06 then NomMois$ = "JUIN"      : ' EXIT_SUB
  if m% = 07 then NomMois$ = "JUILLET"    : ' EXIT_SUB
  if m% = 08 then NomMois$ = "AOUT"      : ' EXIT_SUB
  if m% = 09 then NomMois$ = "SEPTEMBRE"  : ' EXIT_SUB
  if m% = 10 then NomMois$ = "OCTOBRE"    : ' EXIT_SUB
  if m% = 11 then NomMois$ = "NOVEMBRE"  : ' EXIT_SUB
  if m% = 12 then NomMois$ = "DECEMBRE"
END_SUB

@Cosmos 70
Tout d’abord : toutes mes excuses pour le vocable que je vais utiliser.
cette façon de programmer n’a qu’un seul et unique qualificatif : c’est de la programmation « sauvage ».
Une autre fois PARDON

Tu ne vois pas que ça m'amuse de t'emm...
Franchement, tu me vois programmer de cette façon?
Un goto c'est parfois bien pratique. Mais généralement c'est qu'en il y aurait complication à ne pas l'utiliser. Car un goto n'est qu'un échappatoire à un problème à mon sens. Et pour les cas particuliers, j'aime autant qu'il ne disparaisse pas.

Vu que l'on me dit souvent que je suis un ours...
...me dire que je fais de la programmation sauvage
ne me semblerait finalement que de très normal...



sauf que je ne suis pas un adepte du goto mais du gosub...
...suis je un peu plus civilisé ?...

« La programmation sauvage » est une expression employée pour designer le contraire de « la programmation structurée » et n’a rien à voir avec « le sauvage » et le « civilisé »

@Cosmos 70
Je savais pertinemment que tu joues à l’emm...
C’est pourquoi je ne t’emm...PLUS !!

PS : sauf quand l’envi devient trop pressant !!



Hé Ours !
OK : Gosub ça fait partie de « la programmation civilisée »

Le comble du Panoramicien...

...A peine Jack lui fournit un moyen d'entrer (sub)
qu'ils commencent déjà à chercher un moyen
de s'en sortir (exit_sub)...




Edit : he !!! Jack !!! Avant de coder Function, commence par coder Exit_Function...

Entrer c’est bien. On se sent à l’abri.
Mais pour sortir à l’air libre , mieux vaut avoir les clés avec soi !

Citation :

Jack !!! Avant de coder Function, commence par coder Exit_Function...

Tu as raison. Et avec toutes ces demandes, je vais bientôt coder EXIT_PANORAMIC

PS: à ne surtout pas prendre au sérieux !

Excellent que tu garde le sens de l'humour Jack et j'espère que tu es fière de nous. Nous sommes bon un pour charger les todo list, non ? Passe une bonne fin de weekend

C'est un nom qui peut remplacer "Terminate", ce serait + panoramicien...

Ah c’est vrai, EXIT_PANORAMIC, c’est beaucoup plus panoramic que TERMINATE, pourquoi pas

Une bonne trouvaille

...Et voilà comment on rajoute 12 pages à un sujet du forum...

Bonjour,
Je suis en train de refaire le pagiciel en me servant des SUB. J'ai une dizaine de formes avec dans les 190 objets.
La vitesse: dans les 1/2 secondes pour voir la page. Il n'y a pas les traitements de fait, mais la partie affichage est faite.
Je crois que je vais faire un zip. Malgré la quantité, on ne voit pratiquement les effets d'installation des objets. Juste pour avoir une idée de la vitesse.