Je dis bizarre

Lorsqu’on appel une SUB en lui transmettant exactement le même nombre de paramètres attendus, alors elle s’exécute normalement. D’ailleurs c’est ce qu’on attend d’elle.
Si on lui transmet un nombre de paramètres plus grand que le nombre de paramètres attendus (ou si on ne lui transmet aucun paramètre) elle se venge en émettant un message d’erreur et ça c’est correct.

Mais si on lui transmet moins de paramètres que ce qu’il est attendu, elle se comporte ainsi :
Le(s) paramètre(s) manquant est (sont) remplacé(s) par le dernier paramètre transmis  et la SUB s’exécute comme si il n’y a rien à signaler et ça c’est bbbiiizzzaaarrreee !!!

Qu’en pensez-vous ?

Code:

test(1,2,3,4) : ' nombre de paramètres transmis = nombre de paramètres attendus : correct c'est normal
' nombre de paramètres transmis < nombre de paramètres attendus ===> PAS D'ERREUR !
test(1,2,3)   : ' le(s) paramètre(s) manquant est (sont) remplacé(s) par
test(1,2)     : ' le dernier paramètre transmis
test(1)       : ' c'est bbbiiizzzaaarrreee !!!
' test()      : ' sans paramètres ===> erreur : c'est normal
' test(1,2,3,4,5) : beaucoup de paramètres === > erreur : c'est normal
end
' ******************************************************************************
sub test(a,b,c,d)
    print a ; " ";b;" ";c;" ";d
end_sub
' ******************************************************************************

Vous pouvez dire que le programmeur devrait faire attention à ce qu’il code.
Il doit veiller à bien s’assurer qu’il a transmit ce qu’il faut etc..
Mais quand on est un peu étourdi comme moi, ne serait-il pas souhaitable que Panoramic soit un peu plus aimable en signalant l’erreur ?

Si si le problème n'est pas nouveau sur la finesse des message d'erreurs. mais bon perso je ne reviens pas dessus. C'est connu et je ne crois pas que Jack ait prévu de retravailler ça pour le moment

Je ne suis pas d'accord. C'est une souplesse, et je dis que Panoramic, dans l'ensemble est plutôt rigide. Cette possibilité existe dan d'autre langage, comme la famille du C. Pour le C il faut définir pour les paramètres par défaut, justement ce qui doit-être par défaut, si le paramètre n'existe pas. Dernièrement j'ai utilisé cette facilité avec Panoramic.
Normalement pour Jack, ce langage est conçu pour les petits programmeurs que nous sommes. Généralement dans toute profession, on est moins rigoureux envers les débutants, ou ceux qui font un métier occasionnel, alors pourquoi être à cheval à ce point sur des principes généraux. Moi j'aurai aimé, avoir d'avantage de souplesse dans certaines instructions: instr() qui ne prend que la première occurance. Mid$( à qui il faut attribuer obligatoirement le 3ème paramètre, ce qui n'est généralement plus le cas dans les autres basics. J'aurai aimé aussi qu'un edit vide, accepte la valeur NUL lorsqu'on n'a pas encore attribué un nombre. On ne peut pas faire:  a%= val(text$(x)) si il n'y a rien dedans. On est obligé de faire plusieurs lignes:
If text$(x) <> ""
  if numeric(text$(x)) = 1
     a%= val( text$(x))
  end_if
end_if

Il y a plein de petites choses pour le programmeur du dimanche à qui on en demande beaucoup, et là je pense qu'on aurait pu être un peu plus tolérant. Donc si pour une fois il y a de la souplesse, je ne vais pas m'en plaindre. Tiens! pour exemple: j'ai horreur de programmer en AutoIt, et pourtant avec ce langage, il y en a beaucoup plus, en dehors du fait que les commandes il faut les trouver. Par exemple, il n'y a qu'un seul type de variable: le mode variant. Une variable peu être numérique, booélienne ou une chaine. Ca n'empêche pas de programmer.
Maintenant il faut penser à chaque débutant, dont certains ont peu d'années d'étude (moi par exemple), et tout le monde n'a pas forcément une logique sans faille.
Ca ce n'est que mon opignion

Comme souplesse, je ne croix pas que c’en est une !

Code:

test(123)

end
SUB test(a,b,c$,x$,y)
    print a;"  ";b;"  ";c$;"  ";  x$ ;"  "; y
END_SUB

Mais chacun est libre de croire ce qu’il vaut.
Ça ce n’est que mon opinion.

J'ai très bien compris, mais tu prends l'exemple qui te convient le mieux.

En voici un autre. On ne sait pas toujours combien de variables qu'on a besoin, et on ne va pas toujours faire une sub à part pour chaque cas particulier.
Excuses-moi pour l'exemple, mais cela fait plus d'une semaine que j'hésite sur la manière de prendre un code, qui dans son développement je me demande ce que je vais choisir, ici je prend un cas simple:

Code:

test(123)

end
SUB test(a,b,c$,x$,y)
    print a;"  ";b;"  ";c$;"  ";  x$ ;"  "; y
END_SUB

cela dit, bonne nuit.

Pardon Cosmos 70,  mais tu as repris mon code !

Effectivement, le voici. Désolé  

Code:

teste(4,"cheval","vache","cochon","canard")
end
sub teste(a%,a$,b$,c$,d$,e$,f$)
dim_local t$ :t$ =chr$(13)

 select a%
  case 1: message a$
  case 2: message a$+t$+b$
  case 3: message a$+t$+b$+t$+c$
  case 4: message a$+t$+b$+t$+c$+t$+d$
  case 5: message a$+t$+b$+t$+c$+t$+d$+t$+e$
  case 6: message a$+t$+b$+t$+c$+t$+d$+t$+e$+t$+f$
 end_select
end_sub

Appelle  la sub comme ceci :

Code:

teste(6, "cheval", "vache")

Le résultat te semble satisfaisant ?

Papydall, je ne te comprend pas. Pourquoi cherches-tu les cross!
Dans cette exemple, je te montre une possibilité avec une seule sub avec des paramètres variables selon le cas, et tu donnes au départ le nombre de paramètres à lire pour l'exécution d'un code, et toi tu tiens à me montrer, que le restant des paramètres n'est pas bon. Quand on fait un programme, on le fait avec une certaine idée de ce que l'on veut faire, sinon des codes à erreurs , je vais en mettre pleins.
Je suppose que celui qui fait un programme, est assez intelligent pour coder proprement, mais toi tu veux faire le contraire.
La sub, tel qu’elle est faite, permet plusieurs possibilités. A toi de respecter ce principe.
On peut, peut-être regretter qu'on ne puisse pas régler les variables optionnelles. Moi je pense que Jack a eu assez de mal à mettre au point le principe des subs, vu que cela n'était pas prévu au départ.

moi, jeudi bizarre. Stop j’arrête. Je ne vais pas tourner continuellement en rond.
Bonne appétit!

Mon opinion la dessus: mieux vaut avoir des messages d'erreurs clairs que de risquer qu'une erreur échappe au programmeur.
Après la "surcharge" de procédure peut être implémentée. Dans ce cas il faut prévoir le comportement.
Par exemple prévoir des valeurs par défaut si certains paramètres ne sont pas renseigner ou avoir des options pour rendre des paramètres optionnels ou obligatoires selon moi.

Ok! mais comment faire?. En C, il y a une déclaration des procédures où effectivement on peut rentrer les paramètres en option. Mais les sub en Panoramic, elles n'ont pas de déclaration, et mieux qu'il en soit ainsi, car il faudra être plus que débutant pour s'en servir, et pour mettre les déclarations où?.

La seule chose plus facile, serait de faire quelque chose ressemblant à cela:
teste("cheval","lion", et
sub teste(a$,b$ , c$[="chat"] ,d$[="chien"] )

En effet cette syntaxe est sympa. Je mettrais même ça sous la forme :
sub test(a$,b$[,c$][,d$="chat"])

Appels corrects:
test("cheval","lion") => a$="cheval", b$="lion", c$="", d$="chat"
test("cheval","lion",,"chien") => a$="cheval", b$="lion", c$="", d$="chien"
test("cheval","lion","chien") => a$="cheval", b$="lion", c$="chien", d$="chat"
test("cheval","lion","chien","lapin") => a$="cheval", b$="lion", c$="chien", d$="lapin"

Bonjour à tous !

Je découvre ce post avec plaisir, ayant découvert cet aspect des SUBs qui m'avait permis d'envisager un travail sur INSTR à l'époque où je ne sais plus qui (  désolé !!!) avait publié une variante permettant de trouver, pour la remplacer, une chaîne de caractères dans une autre. J'ai vite laissé tomber quand j'ai trouvé une suite de SUBs qui convenait mieux que mon usine à gaz, mais c'est juste pour signaler que pour un novice comme moi, cette souplesse était bienvenue. Je vous donne juste comme ça, en passant, le début de mon code (qui n'a donc pas eu de suite), lequel exploitait cette :

• souplesse
  
• imperfection
  
• source possible d'erreur
  

(où le lecteur est invité à cocher son choix)

Entre les parenthèses de la fonction, on a :

1. un paramètre / flag à 0 ou 1 selon qu'on considère que le premier caractère d'une chaîne est le n° 0 (pour indexer une variable) ou 1
   un second flag (facultatif, donc, lui aussi !) indiquant que l'on veut faire subir un traitement à la chaîne de caractère (ici supprimer chaque a)
   la chaîne à trouver
   la chaîne à explorer
   la chaîne à insérer
   un flag qui donne ou pas la (les) position(s) où l'on a trouvé le texte...
   

Code:

dim i%,c$
dim FgRep%,FgPos%,FgKil%

' InstrPlus("ram","Panoramic","troulala")
InstrPlus(0,"azcza","Panoramic")   :' Pazczanorazczamic
InstrPlus(0,0,"a","Panoramic",1)   :' Pnrormic 1 5
InstrPlus(1,"azcza","Panoramic")   :' Pazczanorazczamic
InstrPlus(1,0,"a","Panoramic",1)   :' Pnrormic 0 4

end

'sub InstrPlus(serie$,chaine$,modif$)

SUB instrPlus(e1$,e2$,e3$,e4$,e5$,e6$)

    IF e1$="1" : FgPos%=1 : END_IF
    IF e2$="1" : FgKil%=1 : END_IF
    IF e6$="1" : FgRep%=1 : END_IF

END_SUB

Bonne journée !!!

PS Apparemment les balises ont un comportement étrange...