Discussion :

[Ry_Yo]

Histoire d'abaisser le niveau un peu et de revenir sur l'énumération des trucs mal conçu de Windev (je trouve...) :

Si en test on veut se servir d'une ligne de commande, cette dernière est liée au projet, pas au développeur.
Moralité, 2 dev. avec le GDS, vont passer leur temps à redéfinir la ligne de commande de test s'ils testent différents paramètres. Car à chaque fois, il y a extraction et ré-intégration du wdp pour mémoriser la ligne de commande test.

Il aurait été plus judicieux de mettre la configuration de la ligne de commande en test au niveau du développeur et pas au niveau du projet.

Le danger c'est donc d'extraire en test le .wdp pour pouvoir faire ses tests tranquille, mais d'oublier d'annuler cette extraction... et de continuer à développer dessus... bonjour les désynchros avec les autres dév. lors d'ajout ou suppressions d'élément dans le projet...

---

La fonction iEnchaînementImprime() aurait pu être mieux :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
iAperçu()
iEnchaînementAjoute(ETAT_Etat1)
iEnchaînementAjoute(ETAT_Etat2, 3)
iEnchaînementImprime()

Ok pour ce type de fonctionnement, mais maintenant imaginons que je veuille grouper les factures d'un client dans une seule impression :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
HLitPremier(...)
Tantque ...
iEnchaînementAjoute(ETAT_Etat1,IdFacture)
FIN
iEnchaînementImprime()

[/CODE]

la fonction iEnchaînementAjoute(ETAT_Etat1,IdFacture) ne conserve pas le contexte de la variable...
Donc si on avait 5 factures... On aura 5 impressions identique, avec le dernier numéro de facture trouvé...

[Hibernatus34]

Si en test on veut se servir d'une ligne de commande, cette dernière est liée au projet, pas au développeur.

[...]

Le danger c'est donc d'extraire en test le .wdp pour pouvoir faire ses tests tranquille, mais d'oublier d'annuler cette extraction... et de continuer à développer dessus... bonjour les désynchros avec les autres dév. lors d'ajout ou suppressions d'élément dans le projet...

Mille fois d'accord. On a eu le problème nous aussi.

Tatayo : mais ce qu'il faut comprendre, c'est que les 2 "variables", même si elles avaient eu le même nom, ne sont pas la même chose. Relisez mon 2ème post pour comprendre pourquoi. Vous vous retrouverez avec 2 choses portant le même nom, je ne vois pas en quoi c'est plus propre, au contraire.

Chez nous, la règle est de ne jamais déclarer une variable ayant le même nom qu'une "variable de boucle". (je sais pas comment appeler ça puisque c'est pas une vraie variable)
Et on s'en porte très bien.

[tatayo]

Je viens de tester le code en question, et effectivement le comportement est... bizarre.
Mais il ne me fait pas changer d'avis. Je n'aime pas les déclarations implicites, surtout que WinDev est sensé être un langage déclaratif.

Mais je comprends tout à fait que d'autres puissent se servir de ce comportement, d'où le désactivable.

Tatayo.

P.S. je savais bien que je n'aurais pas dû entrer dans le débat

[Emmanuel Lecoester]

Histoire d'abaisser le niveau un peu et de revenir sur l'énumération des trucs mal conçu de Windev (je trouve...) :

Si en test on veut se servir d'une ligne de commande, cette dernière est liée au projet, pas au développeur.
Moralité, 2 dev. avec le GDS, vont passer leur temps à redéfinir la ligne de commande de test s'ils testent différents paramètres. Car à chaque fois, il y a extraction et ré-intégration du wdp pour mémoriser la ligne de commande test.

Il aurait été plus judicieux de mettre la configuration de la ligne de commande en test au niveau du développeur et pas au niveau du projet.

Le danger c'est donc d'extraire en test le .wdp pour pouvoir faire ses tests tranquille, mais d'oublier d'annuler cette extraction... et de continuer à développer dessus... bonjour les désynchros avec les autres dév. lors d'ajout ou suppressions d'élément dans le projet...

---

La fonction iEnchaînementImprime() aurait pu être mieux :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
iAperçu()
iEnchaînementAjoute(ETAT_Etat1)
iEnchaînementAjoute(ETAT_Etat2, 3)
iEnchaînementImprime()

Ok pour ce type de fonctionnement, mais maintenant imaginons que je veuille grouper les factures d'un client dans une seule impression :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
HLitPremier(...)
Tantque ...
iEnchaînementAjoute(ETAT_Etat1,IdFacture)
FIN
iEnchaînementImprime()

[/CODE]

la fonction iEnchaînementAjoute(ETAT_Etat1,IdFacture) ne conserve pas le contexte de la variable...
Donc si on avait 5 factures... On aura 5 impressions identique, avec le dernier numéro de facture trouvé...

Je le vois plus comme 6 d'évolutions : 1 pour le gds et 1 pour l'impression. Oui çà fait 2 mais n'oubliez pas il y a WD, WB, WM

[OnePoint]

Le sens [de ma question] était: est-ce que vous en programmez souvent [des procédures récursives] ?

Que tu utilises ou non une fonctionnalité n'est pas le problème.


Le sens de ma question était "qu'est-ce qui justifie de brider la profondeur des appels récursifs ?"

En l'état (sans bridage) n'importe quel langage dont les appels de procédures/fonctions sont basés sur l'utilisation de la pile autorise une récursivité maximale.

Cette capacité découle de la conception du langage.
La récursivité en est une "propriété".
C'est un bénéfice qui ne coûte rien à développer pour PC SOFT.


Voici une analogie pour ceux qui ne veulent pas comprendre.

Dorénavant la capacité d'une table de données HyperFile est limitée à 600 enregistrements, au motif que j'ai décidé que c'est bien suffisant.

Comment ?... Que dis-tu ? ...
Ça pourrait poser un problème si tu as besoin de stocker plus de 600 enregistrements ?

Voyons voir...
Mais bien sûr, pas de problème, tu peux contourner ce bridage. Tu n'as qu'à utiliser une table supplémentaire...

Non !? Tu veux vraiment tout mettre dans la même table ?

Oui, j'admets que les limites réelles du système de fichiers sont loin d'être atteintes.
Mais non, notre produit n'est utilisé que par des clients qui se contentent de 600 enregistrements par table.

Alors tant pis, si tu veux tous les enregistrement dans une seule table, tu dois utiliser un autre SGBD.

Quoi ? Encore une remarque ?

Que se passe-t-il le jour où, par mégarde, un client fini par atteindre cette limite pourtant "bien suffisante" de 600 enregistrements ?

Voyons voir...
Le client n'a qu'à migrer sa base de données vers un autre SGBD, évidemment.

Tu vois bien que ce raisonnement est absurde.

Et c'est ce raisonnement qui m'amènerait à développer une bibliothèque en langage C / C++ pour supporter une récursivité d'une profondeur de 600+1, au motif que 600 c'est la limite (arbitraire) de Windev ?

Absurde, je te dis.


C'est pour ça que je clame :

" le bridage de la récursivité n'a pas de sens !"

Toujours pas convaincu ?
Prenons le raisonnement inverse :

Postulat:
" personne n'utilise la récursivité à une profondeur d'appels supérieure à 600 ".

Bien.

Si ça n'existe pas, il n'y a alors pas de risque de débordement de pile.
Si la pile ne déborde pas, alors le bridage de la profondeur d'appel n'a pas de raison d'être.

CQFD

P.S.
En relisant ce message (un peu délirant, je l'admets), je me rends compte que c'est ce genre de situation absurde qui dévalorise l'image de WinDev et du WLangage auprès des "vrais développeurs".
(non pas de polémique. J'utilise WinDev et, tout comme vous, je suis un vrai développeur)

[OnePoint]

Une statique locale c'est l'horreur. Une globale de collection de procédure ou de classe fera l'affaire.

Dire que c'est " l'horreur " ne te dispense pas d'argumenter.

Moi je ne vois pas pourquoi ce serait plus horrible que la "variable globale" d'une collection de procédure.

• "Fausse bonne idée" des variables d'itération qu'il n'est pas nécessaire de déclarer. Pratique ? peut-être, mais rigoureux sûrement pas.

Questions:
(1) comment le compilateur devine-t-il le bon type de de données à utiliser ?
(2) (exemple vécu) en cas d'erreur de frappe, on se retrouve avec 2 variables: une première déclarée explicitement et une deuxième (celle avec une faute de frappe) déclarée "automatiquement".
Un bug de programmation difficile à détecter pour les débutants.

Pas d'accord du tout. Rien n'oblige à l'utiliser, mais c'est franchement mieux.
Le type, WinDev le déduit naturellement et ça évite justement que le développeur se trompe entre chaîne/entier/variant, entre référence à l'objet et copie de l'objet, etc.
Ca permet de limiter naturellement l'usage de la variable à la boucle, et de ne pas rendre le code inutilement long.
J'utilise ça tout le temps et je n'ai jamais eu de problème.

Ceci me laisse songeur...

"Rien n'oblige à l'utiliser"

Sans vouloir l'utiliser, je dis que c'est une cause possible de bug, conséquence d'une erreur de frappe sur un nom de variable par exemple.

"ça évite justement que le développeur se trompe..."

As-tu envisagé que le développeur qui a codé l'interprète du WLangage puisse lui aussi se tromper parfois ?
Ou encore qu'il n'ait pas prévu tous les cas possibles ?

Moralité :
(1) Si tu as ne serait-ce qu'un léger doute sur l'infaillibilité de WinDev/WLangage, alors déclare tes variables.
(2) Si un développeur ne maîtrise pas le choix du type de données correct à utiliser pour la déclaration de la variable d'itération, je lui conseille de se former.

[Hibernatus34]

Non, toujours pas d'accord.

Il y a plein de limites partout, il suffit simplement qu'elles soient raisonnables.
Quelques exemples : http://doc.pcsoft.fr/fr-fr/?3084035

Concernant la récursion, je pense que PC Soft préfère simplement une erreur WL maîtrisée à un stack overflow, et cette erreur révèle un sérieux problème du côté du développeur.
Plus de 600 récursions ce n'est pas raisonnable, là c'est à vous de vous remettre en question.

Imaginez un arbre binaire équilibré de profondeur 600, ça ferait environ 4 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 feuilles.

Si vous y tenez, utilisez votre propre pile, tout algo récursif peut s'écrire en itératif.

Dire que c'est " l'horreur " ne te dispense pas d'argumenter.

Une statique locale implique une instanciation et initialisation au premier appel de fonction, une chose difficile à maîtriser.
En multithread je vous dis pas la joie que c'est.
C'est également trompeur, et c'est un concept qui n'a eu aucun succès dans les autres langages, souvent considéré comme une mauvaise pratique.
L'horreur, quoi.

Ceci me laisse songeur...

"Rien n'oblige à l'utiliser"

Sans vouloir l'utiliser, je dis que c'est une cause possible de bug, conséquence d'une erreur de frappe sur un nom de variable par exemple.

"ça évite justement que le développeur se trompe..."

As-tu envisagé que le développeur qui a codé l'interprète du WLangage puisse lui aussi se tromper parfois ?
Ou encore qu'il n'ait pas prévu tous les cas possibles ?

(1) Si tu as un léger doute sur l'infaillibilité de WinDev/WLangage, alors déclare tes variables.
(2) Si un développeur ne maîtrise pas le choix du type valable à utiliser pour la déclaration de la variable d'itération, je lui conseille de se former.

Concernant l'infaillibilité que je prêterais à PC Soft/WinDev, lire le 1er message.

La "variable" que vous pensez utiliser dans la boucle est un alias, et dans le cas où une variable de même nom existe, la valeur derrière cet alias est copiée à chaque modif dans la variable. Pour une démonstration, lire mon dernier message de la page précédente.
Vous rigolez au point (2), mais je crois que vous ne savez justement pas que votre "variable" n'existera pas si vous ne la déclarez pas, et si vous la déclarez ça sera une sorte de copie carbone.

Au lieu d'essayer de faire rentrer un cube dans le trou rond, essayez de comprendre et d'utiliser au mieux l'outil.

[OnePoint]

Il y a plein de limites partout, il suffit simplement qu'elles soient raisonnables.
Quelques exemples : http://doc.pcsoft.fr/fr-fr/?3084035

J'ai suivi le lien que tu donnes et, première chose que je lis :

le nombre de fenêtres par projet est illimité

! mort de rire !

Comme argumentaire, ça commence plutôt mal.

Concernant la récursion, je pense que PC Soft préfère simplement une erreur WL maîtrisée à un stack overflow, et cette erreur révèle un sérieux problème du côté du développeur.
Plus de 600 récursions ce n'est pas raisonnable, là c'est à vous de vous remettre en question.

Imaginez un arbre binaire équilibré de profondeur 600, ça ferait environ 40000...0 feuilles.

C'est vraiment n'importe quoi de lire ça !

Tu mélanges les genres :

• il y a le cas où la limite est la conséquence d'une contrainte matérielle ou d'un choix de conception, là d'accord.

• il y a les limites organisées, façon "WinDev express", où le but est de t'empêcher d'utiliser le produit comme tu veux, un bridage généralisé.

• et enfin il y a les limites "pour mon bien" (c'est ce que tu dis) ! Et comment toi tu saurais mieux que moi, ce qui est bon pour moi ?


Regarde encore comme c'est absurde :

Pour éviter une erreur de dépassement de pile, WinDev va provoquer une autre erreur, mais celle-là à cause du dépassement d'une " limite factice ", qui n'est ni une limite matérielle, ni une limite de conception.

Au nom d'un risque potentiel, PC SOFT troque (i) une erreur "possible" contre (ii) une autre erreur, mais certaine celle-là !!!

Mais quel "vrai développeur" pourrait trouver ça normal ?

Si vous y tenez, utilisez votre propre pile, tout algo récursif peut s'écrire en itératif.

Eh bon sang, mais pourquoi devrais-je coder mon propre système récursif, au seul motif que celui inhérent au langage a été bridé ???

Qu'on nous donne la clé du bazar, et qu'on nous laisse prendre nos responsabilités !
Je n'ai pas demandé à être materné.

Non vraiment, ça ne tient pas la route.


Et puis, plus philosophiquement, ça a aussi une conséquence par extension.

Si tu admets que telle ou telle fonctionnalité soit bridée "pour ton bien", alors tu acceptes tacitement tous les bridages suivants que PC SOFT décidera "pour ton bien", sans discussion possible.

Céder un peu, c'est céder sur tout !

[Hibernatus34]

J'ai suivi le lien que tu donnes et, première chose que je lis :

le nombre de fenêtres par projet est illimité

! mort de rire !

Comme argumentaire, ça commence plutôt mal.

C'est une page pleine de limites, sur le nombre de variables par exemple.
Si ça vous fait mourir de rire, tant mieux, c'est bon de rire parfois.

C'est vraiment n'importe quoi de lire ça !

Tu mélanges les genres :
[...]

Je vous dis qu'un stack overflow peut être irrattrapable pour WinDev et que leur solution de limiter à 600 récursion pour sortir une erreur WL propre me paraît raisonnable. N'oubliez pas non plus que WinDev c'est une machine virtuelle, et ce que vous pensez être la stack ne l'est peut-être pas.

[mail.spam]

Euh je veux juste recentrer un peu la discussion.
Les limites d'un logiciel sont les choix des concepteur du logiciel. Certaines peuvent vous sembler un injustifiée mais c'est les limites du logiciel.
Quand Microsoft limitait le nombre de lignes d'un fichier Excel ça ne gênais personne.
Il faut aussi se demander si windev est le logiciel le plus approprié pour faire plus de 600 récursivités.
Je suis d'accord que le logiciel n'est pas parfait et que d'ouvrir des discussions expliquant les limites peux peut être faire évoluer les versions.
Mais il faut rester dans les critiques constructives.



Sinon OnePoint peut tu dire dans quel cas tu as eu besoin de plus de 600 niveau de récursivités.

[OnePoint]

La "variable" que vous pensez utiliser dans la boucle est un alias, et dans le cas où une variable de même nom existe, la valeur derrière cet alias est copiée à chaque modif dans la variable. Pour une démonstration, lire mon dernier message de la page précédente.
Vous rigolez au point (2), mais je crois que vous ne savez justement pas que votre "variable" n'existera pas si vous ne la déclarez pas, et si vous la déclarez ça sera une sorte de copie carbone.

Au lieu d'essayer de faire rentrer un cube dans le trou rond, essayez de comprendre et d'utiliser au mieux l'outil.

D'accord, je suis convaincu de l'intérêt de la chose.

Ce n'est pas une variable, c'est un alias et par conséquent il ne saurait y avoir d'erreur de type de données.

En fait, c'est la même chose qu'un paramètre formel non typé d'une procédure :
c'est à dire qu'il "est" le paramètre réel, mais sous un autre nom.

Alors, allons au bout :
(1) pourquoi demander au développeur de lui donner un nom et
(2) pourquoi dans la documentation dire "Il n'est pas nécessaire de déclarer cette variable." si ce n'est pas une variable.

Nous sommes déjà habitués à utiliser un mot-clé en lieu et place d'une pseudo-variable.

Par exemple:
MoiMême, MaFenêtre, MonEtat, MonParent, MonFichier, MaSource, objet

Alors, je suis convaincu qu'il eut été préférable de fixer le mot-clé à utiliser , par exemple MonElément.

Et ainsi, pas de "nom de variable", pas de doute, pas de bug d'erreur de frappe...
hé oui, je te rappelle que le point de départ de cet échange est le constat qu'il y a un risque de bug en cas d'erreur de frappe sur le nom d'une variable utilisée pour l'itération.

[Hibernatus34]

La réponse est simple : boucles imbriquées.
Mais même, ça a d'autres avantages, car nommer correctement une variable permet souvent que le code soit plus explicite.

[OnePoint]

La réponse est simple : boucles imbriquées.

Mouais... et s'il n'y a pas d'imbrication ?

Pourquoi se priver de la rigueur ?

Mais même, ça a d'autres avantages, car nommer correctement une variable permet souvent que le code soit plus explicite.

Alors il faudrait remplacer MaFenêtre par un autre nom plus explicite ???

MonElément, n'est pas assez explicite dans une itération ?
Allez, je propose ElémentEnCours.

[Hibernatus34]

On va pas faire une dissertation là-dessus, mais bon...

La comparaison n'est pas tout à fait opportune :
- MoiMême peut être utilisé dans une fonction, il peut alors désigner le champ A lors d'une 1ère exécution, le champ B dans une autre.
- MoiMême désigne la même chose durant l'exécution de toute une fonction.

(c'est aussi vrai avec les autres : MaFenêtre, MonEtat, etc.)

Bref, ça fait partie d'un contexte d'exécution, au-dessus de la fonction, et non à l'intérieur.

[mail.spam]

Bonjour,
Je répète on sort du cadre bug et erreurs de conception. Je trouve que la conversation ressemble plus à "bah moi j'aurais pas fait comme si pour faire Windev mais plutôt comme ça".
Le but de tout développeur qui utilise Windev est d'avoir un logiciel le plus adaptée ses besoins et donc on recense les bug bloquant. Si la conversation tourne à un concours de bah moi et nananere et puis moi.. (ce qui pour l'instant en prend le chemin) cette conversation n'a plus l'intérêt des premiers messages de cette conversation.

[OnePoint]

Quand Microsoft limitait le nombre de lignes d'un fichier Excel ça ne gênais personne.

Désolé, mais là encore, c'est de la mauvaise foi, car dans le cas d'Excel il s'agit de limitations induites par l'état de l'avancement des technologies et d'un "niveau de réponse" qui était alors approprié aux besoins des utilisateurs.

Niveau de réponse qui n'a cessé de s'adapter pour toujours plus de possibilités:
• versions d'Excel jusqu'à 95, 16.384 lignes x 256 colonnes
• versions suivantes jusqu'à 2003, 65.536 lignes x 256 colonnes
• versions récentes, 1.048.576 lignes x 16.384 colonnes

Et que dire de son ancêtre Multiplan, limité à 255 lignes x 63 colonnes.

Pour aller au bout de ta "malheureuse" comparaison avec Excel,
j'aimerai bien que la limitation de la profondeur d'appels de fonctions dans le WLangage suive la même progression que celle des feuilles de calcul d'Excel.

Il faut aussi se demander si windev est le logiciel le plus approprié pour faire plus de 600 récursivités.
Je suis d'accord que le logiciel n'est pas parfait et que d'ouvrir des discussions expliquant les limites peux peut être faire évoluer les versions.
Mais il faut rester dans les critiques constructives.

Je crois que vous ne comprenez pas où se situe l'enjeu.

Ici, il ne s'agit pas de savoir si WinDev/WLangage est adapté ou non.
Comme je l'ai dit plus haut, la récursivité est une "propriété naturelle" inhérente à ce type de langage.

Et il s'agit de savoir au "nom de quoi" cette fonctionnalité est bridée, parce que techniquement WinDev/WLangage est capable.

Comme je l'ai démontré plus haut, si le "développeur type" n'utilise pas la récursivité, alors le risque n'existe pas, par conséquent, nul besoin de brider.

C'est simple, logique, imparable.

Mais bon je constate aussi notre incompréhension et je conclurai par

"Bonne nuit !"

[Arnaud B.]

OnePoint, Hibernatus34,

Pour en finir avec votre désaccord (et bien que je comprenne les 2 points de vue), je lance la conversation sur ce qu'on appelle le "sucre syntaxique", car personnellement dans Windev je trouve dommage que :

1°) on soit obligé d'écrire pour déclarer les variables :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

dDateDébut est une Date, eNbJours est un Entier

au lieu de, comme dans quasi tous les langages :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

dDateDébut Date, eNbJours Entier

ou encore mieux car plus clair et similaire à la plupart des langages :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Date dDateDébut, Entier eNbJours

car cela alourdit considérablement tant l’écriture que la lecture...

2°) on ne puisse pas passer des paramètres à une procédure en les nommant
Plutôt qu'en les passant dans l'ordre requis, qu'il n'est pas toujours facile de connaitre.
Par exemple avec une syntaxe comme :
soit une procédure :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

maProcédure(paramA est chaine, paramB est entier, paramC est entier, ...)

et l'appel :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

maProcédure(:paramB = 10, :paramA = «toto» :paramC = 5)

Améliorerait la visibilité du code. Ce type de syntaxe existe en VB ou dans le langage Nice.

Autres manques que j'ai en tête :

3°) l'absence de variables Nullable
Actuellement seuls les variants peuvent être Nullable.
Pouvoir définir si une variable est nullable ou non se ferait à la déclaration.
De plus, le compilateur pourrait nous signaler les variables non Nullable qui seraient restées à Null.

4°) Pouvoir définir qu'une valeur d'un paramètre par défaut est donnée par une méthode
Exemple en java :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

void extraire(File de, File vers, long taille = de.length())

5°) Pouvoir créer ses propres types :
Par exemple avec une syntaxe comme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Température est un type Réel compris entre -20 et 37,5 
NbEnfantsPair est un Entier dans (0;2;4;6)

déclaration :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
temp1 est un Température
nbenf1 est NbEnfantsPair

affectation :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
temp1 = 80 // doit provoquer une erreur de compilation
nbenf1 = 3 // doit provoquer une erreur de compilation

Une telle syntaxe existe en Ada ou en Pascal par exemple.

[Hibernatus34]

4°) Pouvoir définir qu'une valeur d'un paramètre par défaut est donnée par une méthode
Exemple en java :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

void extraire(File de, File vers, long taille = de.length())

Ca fonctionne déjà. (et à ma connaissance ça n'existe pas en Java, ou alors dans une version récente)

Sinon, comme l'a déjà dit mail.spam, on est déjà loin du sujet initial qui était les fautes de conception. Ce que j'entendais par là, c'est des fautes commises sur une fonctionnalité, qui vont à l'encontre du bon sens ou du sens commun, et qu'on pourrait même presque appeler bug.

Quand la fonction dCopieImage inverse hauteur et largeur, ou quand le ET n'a pas priorité sur le OU, on se doute bien que quelqu'un s'est pris les pieds dans le tapis. Pourtant ça ne sera pas pris pour un bug et jamais corrigé.

Pour vos doléances un peu plus générales, vous pourriez peut-être ouvrir une discussion intitulée "Si j'étais PC Soft...".

[Emmanuel Lecoester]

Je rejoins totalement mail.spam .

Concernant la déclaration des variables c'est une base de chaque langage de programmation donc on fait avec .

Concernant la profondeur de recursivité je veux bien un exemple pour arriver à plus de 600 appels pour parler d'une limitation. Je préfère aussi bien d'un point de vue utilisateur final que de développeur avoir une anomalie "Valeur limite de 600 appels atteinte" plutot qu'une erreur "erreur dans la dll WDxxx.dll, la mémoire ne peut être read".

[OnePoint]

Concernant la profondeur de recursivité je veux bien un exemple pour arriver à plus de 600 appels pour parler d'une limitation. Je préfère aussi bien d'un point de vue utilisateur final que de développeur avoir une anomalie "Valeur limite de 600 appels atteinte" plutot qu'une erreur "erreur dans la dll WDxxx.dll, la mémoire ne peut être read".

Prendre l'exemple LST n°83 : WD Tableur Simplifié.

L'utilisateur remplit un bloc de cellules (autant de lignes que de colonnes) dans lesquelles il écrit des formules de calcul qui s'enchaînent.

Exemple de remplissage pour un bloc de 4 lignes par 4 colonnes:

Code Utilisation du composant interne Tableur simplifié :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
      A       B         C         D
1    =1       =A1+1     =B1+1     =C1+1
2    =D1+1    =A2+1     =B2+1     =C2+1
3    =D2+1    =A3+1     =B3+1     =C3+1
4    =D3+1    =A4+1     =B4+1     =C4+1

Si l'utilisateur remplit un plus grand bloc de cellules en conservant le même principe...
d'après-vous, comment se comportera le tableur codé en WLangage ?

Devrait-il y avoir une limite ?

Et s'il y a une limite, quelle est-elle ?
un bloc de 100 lignes x 100 colonnes ? plus ? moins ?

...

Essayez de répondre en toute honnêteté, merci.