[24i2] Au sujet de DIM_LOCAL

@Jack:
Je suis content de voir que tu es d'accord avec mon opinion sur les variables locales.

En ce qui concerne les fonctions, je comprends parfaitement la difficulté devant laquelle tu te trouves pour gérer l'appel d'une fonction Panoramic à l'intérieur d'une expression. Pour ma part, la simple affectation mavariable=mafonction(...) avec les paramètres et variables locales gérées comme dans les procédures, résoudrait 90 % des utilisations que je compte en faire. Personnellement, je voterait pour une implémentation de ce type. Et je pense que si plus tard l'envie te prend d'aller plus loin, ce sera toujours possible et pas contradictoire avec la première option.

Moi, ça me conviendrait parfaitement aussi et je comprends tout à fait le travail énorme que représenterait l'autre méthode. Je pense qu'il ne faut pas trop se disperser et déjà bien tester / exploiter cette grosse avancée. C'est déjà énorme

Pour le dim on partirait donc bien vers leur suppression complète en fin de traitement ?

Le gros avantage de cette méthode et de créer des variables totalement autonomes par exemple est comme le disait Nardo de permettre à une procédure de s'appeler elle même sans que les variables ne perde ses valeurs même si elles sont initialisées au début.
Dans cette méthode il faut en effet forcément qu'elle soit libérée en fin de traitement pour éviter la saturation de la mémoire

Tout comme Klaus, une simple affectation v = fonction(x) me conviendrai parfaitement.

Juste pour savoir:
Pour les dim_locaux on tendrais vraiment vers une gestion dynamique (alloc/free) de la zone 'variable locale' ou une raz auto d'une seule zone par DIM_LOCAL ?

Car apparemment vue la version 24i2, Jack alloue une bonne fois pour toute une seule zone, unique, de variable par procedure/fonction...

Dans mon esprit, tout ce qui est alloué par DIM_LOCAL doit obligatoirement être "oublie", supprimé automatiquement à la sortie de la procédure ou de la future fonction, exactement comme si l'on avait fait explicitement un FREE sur toutes les variables définies par DIM_LOCAL, et ce quella sortie soit faire par END_SUB/END_FUNCTION ou les éventuiels EXIT_SUB/EXIT_FUNCTION. Ainsi, DIM_LOCAL peut tester si une variable a déjà été déclarée par DIM_LOCAL dans la même procédure et produire une erreur dans ce cas, et également si une variable dans un DIM_LOCAL porte le même nom qu'un paramètre formel de la procédure ou de la fonction.

Maintenant, on peut débattre de la visibilité.

1. Une variable déclarée par DIM, n'importe où dans le programme, est visible partout et reste présente et définie, même si elle a été déclarée par DIM dans une procédure, même après la sortie de la procédure. Elle est visible dans toutes les procédures - c'est une variable globale.

2. Une variable définie par DIM_LOCAL n'a d'existence qu'à l'intérieur de la procédure qui la déclare. Elle n'est pas visible dans le programme principal, ni dans une procédure ou fonction qui aurait appelé la procédure déclarant cette variable.

Mais, pour la visibilité "en-dessous", il y a deux conceptions différentes qui se valent:
2.1. une variable déclarée par DIM_LOCAL est STRICTEMENT personnelle à la procédure qui la déclare. Elle n'est pas non plus visible dans une procédure qui serait appelée par la procédure déclarante
2.2. une variable déclarée par DIM_LOCAL est visible dans toute l'arborescence de fonctions et procédures appelées à partir de la procédure déclarante. C'est en somme une variable globale restreinte à l'hiérarchie des procédures et fonctions à un instant donné.

Personnellement, j'opterais pour la solution 2.1 qui a l'avantage d'être parfaitement claire et évite toute confusion.

Je vais revenir sur un autre élément tout aussi important que les variables locales: se sont les labels locaux. A mon sens, il faut avoir une commande similaire pour les labels: LABEL_LOCAL nom, ... déclarant des labels devant impérativement être situés physiquement entre SUB et END_SUB et qui sont SUPPRIMES par END_SUB/END_FUNCTION ou EXIT_SUB/EXIT_FUNCTION, exactement de la même manière que les variables.

Ceci est essentiel, au minimum pour la gestion de la commande ON_ERROR_GOTO qui a absolument besoin d'un label. Et dans une procédure, ce label doit être local et ne pas rentrer en conflit avec des labels du programme principal ou des labels dans d'autres procédures.

Etant donné que certains (et j’en fais partie) sont avides d’utiliser au plus vite les fonctions, je pense que pouvoir faire (après avoir défini MaFonction, bien sûr !)

Code:

.....
x = .....
y = .....
z = .....
t = MaFonction(x,y,z)
w = (3*t + 1/t) * cos(x)
.....

est suffisant dans la majorité des situations.

Alors, Jack, puisque tu as dis toi-même que ce genre de code ne nécessite pas plus que quelques heures de travail, je me rejoins à Klaus et à Nardo26 pour disposer de cette façon de faire, quitte à l’améliorer plus tard.
Ipso facto, c’est à toi de décider.

Je suis d'accord aussi. Suffit de dire les restrictions actuelles dans la doc et tout le monde comprendra.

Perso, je suis pour le choix 2.1 aussi.

Que pensez-vous si on pouvait faire des procédures et/ou fonctions imbriquées ?

Code:

SUB proc1(....)
    DIM_LOCAL ....
    SUB proc2(....) : ' déclaration de proc2 à l’intérieur de proc1
            DIM_LOCAL ....
            .... : ' Corps de proc2
    END_SUB : '  fin de proc2
    ....  : '  Suite de proc1
    proc2(....) : ' appel de proc1 à proc2 qui est à l’intérieur de proc1
    .... : '  Suite de proc1
END_SUB : '  fin de proc1

Papydall, je pense que pour le moment, il faut faire simple et ne pas imbriquer les déclaration
Je ferais plutôt comme ça:

Code:

SUB proc1(....)
    DIM_LOCAL ....
    ....  : '  Suite de proc1
    proc2(....) : ' appel de proc1 à proc2 qui est à l’intérieur de proc1
    .... : '  Suite de proc1
END_SUB : '  fin de proc1

SUB proc2(....) : ' déclaration de proc2 à l’intérieur de proc1
    DIM_LOCAL ....
      .... : ' Corps de proc2
END_SUB : '  fin de proc2

Ce que tu propose et bien, ça se rapproche de la programmation objet (un peu) mais je pense que ça éloigne encore un peu plus de l'esprit de simplicité de Panoramic

C’était une simple idée qui a juste effleuré la surface externe de la partie profonde de ce qui me reste du réseau des neurones !

Je pense (et c'est une simple déduction) que pour le moment, Jack isole les procédures tout début, après avoir traité les #INCLUDE, et avant de commencer l'exécution proprement-dite. Ceci veut dire que les procédures sont repérées, peut-être mémorisées séparément, en tout cas connus AVANT l'exécution normale.

Pourquoi ? Parce qu'il n'y a aucune déclaration préalable de la procedure, un peu comme pour les labels avec la commande LABEL. Une procédure peut parfaitement se trouver à la fin du code et pourtant être utilisée bien au-dessus.

Conséquence: une procédure codée à l'intérieur d'une autre procédure est identique à la même procédure codée avant ou après l'autre.

A Jack de confirmer ou infirmer cette impression qui pour le moment n'engage que moi.

EDIT

Dans l'état actuel de la situation, on ne peut pas déclarer une procédure à l'intérieur d'une autre procédure. Cela est rejeté avec une erreur sur la commande SUB intercalée entre un SUB et le END_SUB correspondant. C'est certainement intentionnel.

restons simple...
...Et c'est moi qui dis ça !!

Nardo26 a écrit:

restons simple...
...Et c'est moi qui dis ça !!

je veux bien rester simple.
Mais comment tu fais pour afficher des Smileys comme ceux-ci ?

Klaus a écrit:

2.1. une variable déclarée par DIM_LOCAL est STRICTEMENT personnelle à la procédure qui la déclare. Elle n'est pas non plus visible dans une procédure qui serait appelée par la procédure déclarante

Klaus a écrit:

Je vais revenir sur un autre élément tout aussi important que les variables locales: se sont les labels locaux. A mon sens, il faut avoir une commande similaire pour les labels: LABEL_LOCAL nom, ... déclarant des labels devant impérativement être situés physiquement entre SUB et END_SUB et qui sont SUPPRIMES par END_SUB/END_FUNCTION ou EXIT_SUB/EXIT_FUNCTION, exactement de la même manière que les variables.

Franchement je trouve que c'est le meilleur et le plus simple pour le programmeur.

Je soutiens à fond cette vision. Et Jack tranchera...

A+

papydall a écrit:

Nardo26 a écrit:

restons simple...
...Et c'est moi qui dis ça !!

je veux bien rester simple.
Mais comment tu fais pour afficher des Smileys comme ceux-ci ?

J'utilise le module "custom buttons" sous firefox... que j'ai personnalisé...