Discussion sur la nouvelle structure d'un source PANORAMIC

@Jack
Sur un autre post, tu as écris

Citation :: - la modification la plus importante et qui va changer les habitudes: le source sera structuré.
Je vais imposer une structure au source et limiter le GOTO.
Un source aura au maximum 5 zones:
une zone pour définir les LABEL,
une zone pour définir les DATA,
une zone pour définir les variables DIM,
une zone pour le programme principal (jusqu'à END),
une zone pour les fonctions et sous-programmes.
Un GOTO de la zone du programme principal vers la zone de fonction et sous-programmes ou inversement sera interdit.
Un GOTO d'un SUB vers un autre SUB ou vers un FNC sera interdit, de même qu'un GOTO d'un FNC vers un autre FNC ou vers un SUB sera aussi interdit.

J’adhère parfaitement à ton point de vue.
- Structurer le code source ça permet déjà de le rendre plus lisible, mieux pensé, facile à gérer et à maintenir.
- Limiter (interdire même) l’utilisation de GOTO (sauf pour des situations très particulières) est une très bonne idée !
J’étais, je suis et je serai toujours contre l’utilisation de cette instruction obsolète qui n’a plus sa raison de continuer et qui ne fait que rendre un source inextricable.
Il y a certainement d’autres programmeurs qui ont un autre point de vue concernant l’utilisation du GOTO ; je respecte leur avis mais je n’y adhère pas !
- Je propose la même limitation pour GOSUB (GO to SUBROUTINE) puisqu’on peut appeler une SUBROUTINE du type SUB par son identificateur.

Bon, je laisse les Panoramiciens discuter et débattre de la question.

Bonjour Papydall !

Je partage moi aussi ce point de vue qui me semble couler de source (sans jeu de mots).
Les zones définies pour les LABEL, DATA, DIM et END sont tout indiqués pour un programme organisé et structuré.

Étant donné le structure de Panoramic il me parait aussi normal de limité l'usage du GOTO.
De plus, les GOTO d'une SUB ou une FNC à une autre ça semble tellement illogique... drunken

En règle générale, il vaut mieux se passer de cette instruction qui de toutes les façons peut avantageusement être remplacée.

Pour GOSUB je suis plus partagé...
J'ajout souvent programmer un LABEL avec MENU pour gérer tous les ON xx,MENU.
et ensuite je réoriente vers les sous programmes correspondants avec des IF clic=xx THEN GOSUB zzzzzz. Mais c'est vrai que l'on peut s'en passer ! Wink

Minibug a écrit:: Pour GOSUB je suis plus partagé...
J'ajout souvent programmer un LABEL avec MENU pour gérer tous les ON xx,MENU.
et ensuite je réoriente vers les sous programmes correspondants avec des IF clic=xx THEN GOSUB zzzzzz. Mais c'est vrai que l'on peut s'en passer !

C’est une simple question de gout (ou de préférence) tongue

Personnellement j’opte comme suit :

Code:: rem ============================================================================
rem Exemple de menu
rem Pour choisir un sous-menu, vous pouvez :
rem 1) cliquer sur son nom
rem 2) ou tapper la lettre soulignée correspondante
rem ============================================================================
label Choix
dim i
main_menu 10
   sub_menu 11 : parent 11,10 : caption 11,"Fichier"
   sub_menu 12 : parent 12,11 : caption 12,chr$(9) + "Nouveau"
   sub_menu 13 : parent 13,11 : caption 13,chr$(9) + "Ouvrir"
   sub_menu 14 : parent 14,11 : caption 14,chr$(9) + "Enregistrer"
   sub_menu 15 : parent 15,11 : caption 15,chr$(9) + "Enregistrer Sous"
   sub_menu 16 : parent 16,11 : caption 16,chr$(9) + "Imprimer"
   sub_menu 17 : parent 17,11 : caption 17,chr$(9) + "Quitter"

   sub_menu 20 : parent 20,10 : caption 20,"Edition"
   sub_menu 21 : parent 21,20 : caption 21,chr$(9) + "Annuler"
   sub_menu 22 : parent 22,20 : caption 22,chr$(9) + "Couper"
   sub_menu 23 : parent 23,20 : caption 23,chr$(9) + "Copier"
   sub_menu 24 : parent 24,20 : caption 24,chr$(9) + "Coller"
   sub_menu 25 : parent 25,20 : caption 25,chr$(9) + "Rechercher ..."
   sub_menu 26 : parent 26,20 : caption 26,chr$(9) + "Remplacer ..."

   sub_menu 30 : parent 30,10 : caption 30,"Langues"
   sub_menu 31 : parent 31,30 : caption 31,chr$(9) + "Langue française" : mark_on 31
   sub_menu 32 : parent 32,30 : caption 32,chr$(9) + "English Language"
   sub_menu 33 : parent 33,30 : caption 33,chr$(9) + "Autres "
   sub_menu 34 : parent 34,33 : caption 34,chr$(9) + "Italiano"
   sub_menu 35 : parent 35,33 : caption 35,chr$(9) + "Dutch"

for i = 12 to 17 : on_click i,Choix : next i
for i = 21 to 26 : on_click i,Choix : next i
for i = 31 to 35 : on_click i,Choix : next i
end
rem ============================================================================
Choix:
   select number_click
   ' menu Fichier
   case 12 : Nouveau()
   case 13 : Ouvrir()
   case 14 : Enregistrer()
   case 15 : Enregistrer_Sous()
   case 16 : Imprimer()
   case 17 : Quitter()
   ' -----------------------------------------------------------------------
   ' menu Edition
   case 21 : Annuler()
   case 22 : Couper()
   case 23 : Copier()
   case 24 : Coller()
   case 25 : Rechercher()
   case 26 : Remplacer()
   ' -----------------------------------------------------------------------
   ' menu Langues
   case 31 : message "Langue française par défaut"
   case 32 : message "English Language"
   case 34 : message "Italiano"
   case 35 : message "Dutch"

   end_select
return
rem ============================================================================
SUB Nouveau()
   message "Nouveau"
END_SUB
rem ============================================================================
SUB Ouvrir()
   message "Ouvrir"
END_SUB
rem ============================================================================
SUB Enregistrer()
   message "Enregistrer"
END_SUB
rem ============================================================================
SUB Enregistrer_Sous()
   message "Enregistrer sous ..."
END_SUB
rem ============================================================================
SUB Imprimer()
   message "Imprimer"
END_SUB
rem ============================================================================
SUB Quitter()
   message "Quitter"
END_SUB
rem ============================================================================
SUB Annuler()
   message "Annuler"
END_SUB
rem ============================================================================
SUB Couper()
   message "Couper"
END_SUB
rem ============================================================================
SUB Copier()
   message "Copier"
END_SUB
rem ============================================================================
SUB Coller()
   message "Coller"
END_SUB
rem ============================================================================
SUB Rechercher()
   message "Rechercher"
END_SUB
rem ============================================================================
SUB Remplacer()
   message "Remplacer"
END_SUB
rem ============================================================================

Oui bien sûr Papydall ! et d'ailleurs elle remplace parfaitement le GOSUB !
Voilà un parfait exemple de solution alternative... Wink

Je vais vous faire part de mon opinion sur la "nouvelle structure" d'un programme Panoramic, suggérée par Jack.

Au départ, j'étais enthousiaste. J'aime bien tout ce qui permet de normaliser le codage, d'une manière ou d'une autre. Mais, depuis, j'ai réfléchi et changé d'opinion.

Pour le dire tout de go, un programme comme SYNEDIT_EDITOR, et, je pense, beaucoup d'autres programmes, ne fonctionnera plus. Pour le faire marcher, il faut bien plus que de réarranger un peu le code pour placer certaines lignes dans les sections réservées. Il faut revoir la conception même, et là, on est carrément en rupture par rapport qu sacro-saint principe de la compatibilité ascendante qui était pourtant un argument-clé avancé par Jack.

La même remarque s'applique à la redéfinition de la fonction ADR() qui est utilisée dans des centaines de programmes. Il vaudrait mieux prévoir une nouvelle fonction ABSADR() ou similaire. Mais fermons cette parenthèse, et revenons à la structure générale d'un programme Panoramic.

Dans un programme comme SYNEDIT_EDITOR, de multiples fenêtres peuvent être créées, mais toutes ne servent pas tout le temps. Je ne les crée donc que lors de leur première utilisation, avec leurs objets, mais également avec leurs variables de tout type (même tableaux) et même avec les labels correspondant aux routines évènement de leurs objets et des ON_ERROR_GOTO associés. Il est donc impératif de pouvoir disposer, dynamiquement, et à l'intérieur d'une SUB, des commandes comme DIM et LABEL ainsi que toutes celles créant les objets. Dans certains cas, je supprime ces objets et certaines variables après utilisation, dans d'autres non - c'est selon les fonctionnalités.

Jusqu'à maintenant, Panoramic offrait cette souplesse extraordinaire permettant de créer des codes modulaires structurés sous forme de SUBs qui pouvaient créer leur propre environnement, et même tester si c'est un premier appel ou non en vérifiant l'existance d'une variable par la fonction VARIABLE() ou celle d'un label par la fonction LABEL, idem pour l'existence des objets. Or, la nouvelle structure rend tout cela caduque et tous les programmes ayant tiré avantage de ces possibilités ne marcheront plus.

Je pourrais développer plus en avant, mais je pense que le topo est suffisamment clair ainsi, et je voudrais éviter de pondre une tartine indigeste par sa longueur. Donc, pour faire court, Jack: pour ma part, je suis finalement opposé à cette "nouvelle structure", bien qu'ayant été séduit au départ par le principe. Je pense qu'il faut revoir la proposition...

Sujet: re Lun 29 Oct 2018 - 23:45

Tout à fait d' accord avec toi Klaus.
Même si je ne programme plus pour l'instant à cause de pb physiques
résiduels, je me range à cet avis.

Very Happy

Ca fait plaisir de voir des opposants à ce zonage de code, je pensais être le seul. Je ne suis guère enthousiaste à l'idée de cette nouvelle structure. J'ai tout de suite pensé au problème de la rétrocompabilité, alors j'attend de voir comment jack veut procéder. Comme Klaus, je cré mes variables au fur et à mesure des mes besoins, confinées ou non dans des 'sub', cela m'évite de remonter tout en haut du code pour placer mes 'dim'. Cela devient vite pénible lorsque le code est long.
Personnellement, et quitte à ce que la compilation soit plus longue, je préfèrerais coder sans avoir à à déclarer les 'dim' (excepté les 'dim_local') et les 'label' comme jack l'a évoqué à un moment.

» Discussion sur un jeu genre Mario en Panoramic
» Structure des variables en Panoramic
» [Résolu] problème de structure de Panoramic
» Outil de génération d'une structure Panoramic valide
» Utilitaire Designer: générer une structure Panoramic valide