Discussion :

[bombseb]

oui mais là, encore heureux que windev ne veuille pas compiler ca.... ta variable est locale à ta fonction P_TestValeur, c'est pareil dans tout les langages...

Bon sinon, moi ce que je n'aime pas trop dans windev, c'est qu'on puisse accéder à une fenêtre de n'importe où et n'importe comment

par exemple à un endroit on fait Ouvre(FEN_Toto)
et de n'importe où dans l'appli on peut faire un truc comme FEN_Toto..SAI_Test = "n'importe quoi"

Je trouve que c'est une entorse à la philosophie objet, normalement on devrait d'abord créer une variable de type FEN_Toto, l'instancier, puis faire un FEN_Toto.Ouvrir () (ou à la rigueur Ouvre(FEN_toto))

Car si on veut faire des applis MDI on est obligé de bidouiller (indirection) pour manipuler par prog les fenêtres filles.

Bon sinon, évidemment il y a aussi beaucoup d'avantage à utiliser Windev hein...


EDIT : En gros pour résumer, ce que je trouve dommage dans Windev c'est qu'il n'est pas assez orienté objet

[vmolines]

Parmi les choses anormales en Windev, c'est la gestion des sources données.
Déclarée en tant que variable locale pour recevoir le résultat d'une requête, si on déclare une source de données locale de même nom dans un autre traitement, les deux sources de données sont en conflit.

Exemple :

Code :

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

1
2
3
4
5
6
7
8
Proc1()
sdRequete est une source de données
 
hExecuteRequeteSQL(sdRequete, ...)
POUR TOUT sdRequete
     Proc2()
FIN
HAnnuleDeclaration(sdRequete)

Code :

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

1
2
3
4
5
6
7
8
Proc2()
sdRequete est une source de données
 
hExecuteRequeteSQL(sdRequete, ...)
POUR TOUT sdRequete
     ...
FIN
HAnnuleDeclaration(sdRequete)

> plante


Pour résumer, vous croyez manipuler une variable qui contient un jeu d'enregistrement. Que nenni, vous manipulez en fait une chaine globale "sdRequete". D'ailleurs je crois qu'utiliser "sdRequete" en paramètre de hExecuteRequeteSQL ne pose pas de problème à Windev .

Personnellement, c'est dans mon best of.

[Lo²]

Oui mais sachant que la déclaration d'une source de données permet de manipuler cette source comme un fichier HF et sachant que si on manipule un fichier HF dans tous les sens sans le fermer, on aura le même phénomène.

Pour moi, il s'agit d'un phénomène compréhensible (notez que je n'utilise pas le mot "normal" )

Edit : Si un Houvre est fait, toutes les manipulations précédentes sont perdues, donc il s'agit en effet d'un phénomène regrettable.

Edit 2 : Il est noté dans l'aide qu'une source est globale au projet donc phénomène normal

[=JBO=]

Bonjour à tous,

Message mis à jour par =JBO= le 08/03/2010

L'intervention pertinente de bombseb m'interpelle.

[..]
Je trouve que c'est une entorse à la philosophie objet, normalement on devrait d'abord créer une variable de type FEN_Toto, l'instancier, puis faire un FEN_Toto.Ouvrir () (ou à la rigueur Ouvre(FEN_toto))

Car si on veut faire des applis MDI on est obligé de bidouiller (indirection) pour manipuler par prog les fenêtres filles.

[...]
En gros pour résumer, ce que je trouve dommage dans Windev c'est qu'il n'est pas assez orienté objet

Toujours à propos des concepts "objets" et pour revenir à la question «Windev ou non?»...

Je dirai qu'un développeur totalement "accro" aux objets sera déçu (voire gêné) par les limitations du WLangage et tous les concepts de WinDev "à l'ancienne mode" et non "orientés objet".

[EDIT]
Attention, le paragraphe plus bas est erroné. Je rectifie ici mon erreur.

Il est possible de passer un élément d'IHM (fenêtre ou champ) en paramètre d'une procédure.
Dans le corps de la procédure, le paramètre est alors considéré comme étant "la" fenêtre ou "le" champ correspondant.
Notamment on peut accéder aux propriétés ou modifier leur valeur sans faire d'indirection.
Mais, comme il n'y a pas de gestion de type, on perd les aides à la programmation (complétion du code, aide contextuelle...).
[/EDIT]

[ERREUR "ce paragraphe est erroné"]
Par exemple, je trouve particulièrement irritant dans un appel de procédure de ne pas pouvoir directement passer une référence à une fenêtre ou à un de ses champs (à la place il faut utiliser le nom complet, beurk !).
[/ERREUR]

Si on pousse le concept au bout, avec l'utilisation de composants imbriqués, on arrive vite à une programmation lourde et pénible:

Comment sera désignée la fenêtre fournie par un composant A, inclus dans un composant B, lui même inclus dans mon projet ?

D'ailleurs, on ressent vite cette limitation parce qu'il faut recourir aux "alias", aux "indirections" et à la "compilation dynamique" pour réaliser ce qui serait trivial dans d'autres langages/environnements.
_

[Louis Griffont]

Au niveau objet, c'est clair que Windev est à la ramasse.

[vmolines]

Oui mais sachant que la déclaration d'une source de données permet de manipuler cette source comme un fichier HF et sachant que si on manipule un fichier HF dans tous les sens sans le fermer, on aura le même phénomène.

Pour moi, il s'agit d'un phénomène compréhensible (notez que je n'utilise pas le mot "normal" )

Edit : Si un Houvre est fait, toutes les manipulations précédentes sont perdues, donc il s'agit en effet d'un phénomène regrettable.

Edit 2 : Il est noté dans l'aide qu'une source est globale au projet donc phénomène normal

Concernant le 1er point, je ne suis pas d'accord. Rien ne dit qu'une source de données doit se compoter comme l'accès aux fichier classique, c'est une supposition que vous faîte et qui n'est indiquée nulle part. De plus, l'accès global aux fichiers est une facilité offerte par l'analyse qui est elle aussi très discutable (à mon sens, bien que ce ne soit pas le débat ici).

Pour le Edit2 : je ne suis pas d'accord, extrait de l'aide :

Une source de données déclarée en globale est globale à tous les traitements du projet qui utilisent le contexte HyperFileSQL correspondant à celui où la source de données a été déclarée

.

Ceci indique implicitement qu'une source de données peut être locale. Or ce n'est pas le cas.

Edit : et quand bien même l'aide indiquerait que les sources de données sont globales (sic), il est plus qu'ennuyeux que le compilateur nous laisse joyeusement croire qu'on manipule une variable locale.

[mogwai162]

L'analyse avait sa pleine utilité en WD5.5 et antérieur. Depuis que la description du fichier a été ajouyrtée au fichier et qu'il existe un serveur hyperfile, je ne vois pas porquoi utiliser l'analyse et celle ci pourrait devenir obsolète. Mais vont ils aller dans ce sens ?

En ce qui conerrne la POO... pff... en ce qui me concerrne et même si je ne partage mon avis qu'avec moi-même (lol) je trouve que ça sert a rien.

Mais bon...

[harf18]

En ce qui conerrne la POO... pff... en ce qui me concerrne et même si je ne partage mon avis qu'avec moi-même (lol) je trouve que ça sert a rien.

Mais bon...

Tu parles "en général" ou "dans windev" ?

[_Azul_]

Bonjour

Je pense que vous faites erreur sur ce sujet.

Par exemple, je trouve particulièrement irritant dans un appel de procédure de ne pas pouvoir directement passer une référence à une fenêtre ou à un de ses champs (à la place il faut utiliser le nom complet, beurk !).

Le WLangage permet justement de passer n'importe quoi en paramètre à une procédure : types simples, éléments d'IHM, instances de classe ou de structure, ...
A charge au développeur d'effectuer dans le corps de la procédure des actions autorisées sur l'élément passé en paramètre.
Les supporters de la compilation stricte argueront que ça permet de faire beaucoup d'erreurs mais ça permet surtout de faire aisément du code générique à base de "duck typing".

Pour se rapprocher du sujet initial du thread, un des intérêt de WinDev, c'est justement qu'il se démarque des autres langages, ce qui permet d'autres approches qui sont souvent plus efficaces.

Bons développements

Azul

[mogwai162]

Tu parles "en général" ou "dans windev" ?

Je parle de Windev uniquement. Pour ce qui est du cas général j'ai pas assez de retour d'expérience.

[N_Ron]

Sans la POO, on serait encore à l'âge de Pierre niveau jeu vidéo par exemple. Et les systèmes complexes seraient peu maintenable par un tiers. Alors qu'avec la POO, même s'il faut du temps, toute personne ayant les bases peut comprendre ce que fait votre programme.
En plus cela facilite grandement le partage de source qui fait gagner un temps fou.

La condition est bien entendu d'être beaucoup plus rigoureux pour que tout ça soit valable.
Enfin c'est un point de vue.

[mogwai162]

La condition est bien entendu d'être beaucoup plus rigoureux pour que tout ça soit valable.

Justement, c'est peut être là le souci.

La POO si tu n'as aucune rigueur ça va pas marcher du tout, au contraire de la programmation événementielle qui elle va fonctionner mais parfois plutôt mal.

Mais je ne vois absolument pas pourquoi un bon programmeur aurait besoin qu'on l'oblige à être rigoureux. En informatique on ne peux pas être rigoureux, on doit l'être et ceci quelque soit le langage utilisé.

Seul un code propre et rigoureux pourra vous permettre de modifier sans problème un programme 6 mois après l'avoir écrit.

[Emmanuel Lecoester]

Même si ce débat (POO - événementielle) est passionnant (voir les échanges dans le forum best of), merci de rester sur l'utilisation de WinDev ou non

[=JBO=]

Bonjour à tous,

[EDIT]
Message mis à jour par =JBO= le 08/03/2010

Dans ma grande ignorance, je suis allé un peu vite dans ma réponse à _Azul_.

Donc, oui _Azul_ a raison sur le fait qu'il est possible de passer en paramètre d'une procédure, une "référence" à une fenêtre ou un champ.

Dans le corps de la procédure, le paramètre est alors interprété directement comme étant "la" fenêtre ou "le" champ.
Contrairement à ce que j'ai pu écrire (cf. plus bas), il est donc possible d'accéder aux propriétés et de les modifier via le paramètre, sans faire usage des indirections.

Mais effectivement, ce mode de programmation est risqué (il n'y a pas de contrôle de type) et fait perdre les aides à la programmation de l'éditeur (pas de fonctionnalité de complétion).

De plus, il est pénible de ne pouvoir utiliser cette référence que via le paramètre de la procédure.
Il n'est pas possible de "prendre une référence" au moyen d'une variable, car il n'existe pas de type Fenêtre ou de type Champ.
[/EDIT]

En réponse au message d'_Azul_

Je pense que vous faites erreur sur ce sujet.

Par exemple, je trouve particulièrement irritant dans un appel de procédure de ne pas pouvoir directement passer une référence à une fenêtre ou à un de ses champs (à la place il faut utiliser le nom complet, beurk !).

Le WLangage permet justement de passer n'importe quoi en paramètre à une procédure : types simples, éléments d'IHM, instances de classe ou de structure, ...

Je ne te rejoins pas du tout sur « éléments d'IHM ».

En WD12 (version que j'utilise) il n'existe pas de type Fenêtre ou de type Champ. Donc, il n'y a pas d'autres moyens que d'utiliser leurs noms pour les passer en paramètre d'une procédure.
Et dans la procédure, comme ce nom ne donne pas directement accès aux propriétés (ce n'est qu'une chaîne de caractères), il faut passer par une indirection.

En conclusion: fastidieux, source d'erreur, manque d'efficacité.

A charge au développeur d'effectuer dans le corps de la procédure des actions autorisées sur l'élément passé en paramètre.
Les supporters de la compilation stricte argueront que ça permet de faire beaucoup d'erreurs mais ça permet surtout de faire aisément du code générique à base de "duck typing".

Pour éviter de programmer des lignes et des lignes de contrôles de types, les "bons langages" proposent la surcharge de procédures et de méthodes, qui tient compte du type des paramètres... "automatiquement".

Si on veut faire du générique "basique", on peut toujours se rabattre sur le type Objet ou le type Variant.
_

[klbsjpolp]

Pour éviter de programmer des lignes et des lignes de contrôles de types, les "bons langages" proposent la surcharge de procédures et de méthodes, qui tient compte du type des paramètres... "automatiquement".

Java n'est donc pas un "bon langage" puisqu'il ne permet pas la surcharge des méthodes ou des opérateurs? Tu ne dois pas non plus être un fan de C ou de C++ avec les pointeurs qui ne sont là qu'à titre indicatif (sans parler du void*).

[=JBO=]

Il est bien entendu que je cherche pas à polémiquer.

Pour éviter de programmer des lignes et des lignes de contrôles de types, les "bons langages" proposent la surcharge de procédures et de méthodes, qui tient compte du type des paramètres... "automatiquement".

Java n'est donc pas un "bon langage" puisqu'il ne permet pas la surcharge des méthodes ou des opérateurs? Tu ne dois pas non plus être un fan de C ou de C++ avec les pointeurs qui ne sont là qu'à titre indicatif (sans parler du void*).

Euh... Tu remarqueras que j'avais pris la précaution de placer l'expression "bons langages" entre guillemets, pour signifier qu'il s'agissait d'une libre opinion...
Le langage propose... le développeur dispose: autrement dit, libre à toi d'utiliser ou non les fonctionnalités de ton langage de programmation.
Mais force est de constater que le WLangage est limité, notamment du fait d'une gestion de type totalement dépassée.

Concrêtement: en WLangage, je préfèrerai manipuler directement un type Fenêtre, ou un type Champ, ce qui m'éviterait l'utilisation des indirections.
Et puis, tant que j'y suis, je préfèrerai que les types de très haut niveau soient hiérarchisés dans... une hiérarchie de classes.

Ici, j'appelle "type de très haut niveau" un type qui possède des propriétés (pour rester général).
Quelques exemples, pris parmi les types avancés du WLangage: une description de fichier, une description de rubrique, une source de données...
Autres exemples, les structures prédéfinies du WLangage qui (hélas !) ne permettent pas d'en conserver simultanément plusieurs instances, comme la structure Email, la structure Contact, la structure HoraireTâchePlanifiée, etc.


Et au fait, JAVA permet la surcharge de méthodes, C++ permet la surcharge des opérateurs et des fonctions (y compris les fonctions membre d'une classe)

Tu ne dois pas non plus être un fan de C ou de C++ avec les pointeurs qui ne sont là qu'à titre indicatif (sans parler du void*).

Pourquoi ? J'aime beaucoup le C++ et ses pointeurs hérités du C.
Là encore, C++ te permet de programmer à l'ancienne mode C, tout comme tu peux faire de la programmation objet, etc. Tu as le choix.

Mais je ne comprends pas ce que tu veux dire par «avec les pointeurs qui ne sont là qu'à titre indicatif (sans parler du void*)»
_

[klbsjpolp]

Mais je ne comprends pas ce que tu veux dire par «avec les pointeurs qui ne sont là qu'à titre indicatif (sans parler du void*)»

Ce que je veux dire c'est que si tu reçois un paramètre "int * fTotal", tu ne sais pas si c'est un tableau ou un pointeur et tu n'es pas sûr si c'est un float ou un int. Tu peux donc facilement te tromper ou du moins être déstabilisée.

Je suis parfaitement d'accord avec toi pour avoir une meilleur gestion des objets d'interface et une programmation objet mieux implantée. À quand la prochaine révolution Windev comme la WD5/WD7? Pour la 20 peut-être?..

Pour la surcharge, tu as raison, je devrais éviter de répondre pendant mes cours, je suis pas très attentif.

[Lo²]

Je me trompe sûrement mais j'ai l'impression que le fond de la discussion se transforme plus sur la méthode de travail préférée du développeur (donc subjectif) que des possibilités ou impossibilités de Windev.

Sur ces possibilités, finalement, il semblerait que Windev puisse pas mal de chose mais différemment. Est-ce un point bloquant important pour vous ? Car pour moi, j'aime cette approche d'un problème par un autre point de vue.

[Marco46]

Absolument, sauf que ce n'est pas si subjectif que ça. Le paradigme objet est plus efficace dans un contexte de développement de gestion. C'est un fait indiscutable.

Or Windev est construit sur un paradigme procédural et en plus est trop permissif, le simple fait de pouvoir utiliser des variables non typées comme en PHP ou en Javascript je trouve ça nul et dangereux. Les débutants vont quasi systématiquement utiliser ces facilités pour soi-disant gagner du temps et derrière ils produisent un code touffu et indébugable ce qui conduit au final à une perte sèche de temps.

Lorsqu'il faut autant de temps pour lire le code d'une fonctionnalité que pour l'écrire il y a clairement un problème. Windev permet ce genre d'écriture de part sa permissivité. C'est aussi un principe de fonctionnement qu'ont généralement les plus vieux programmeur (simple constat quotidien), le principe du "ça marche donc c'est ok, on s'en fou de comment c'est fait". C'est une erreur grave à mon sens, la qualité d'un code doit être jugée aussi importante sinon plus car elle détermine si le code peut passer facilement d'un développeur à un autre.

Pour en revenir à l'objet, ce paradigme de prog impose une structure dans le code, et propose des "patterns" c'est à dire des modèles structurels d'organisation du code pour résoudre tel ou tel type de problème. Donc 2 programmeurs objets auront souvent des solutions proches pour résoudre un même problème et s'ils utilisent les patterns ils auront parfois la même solution. Dans un paradigme procédural chacun fait à sa sauce et c'est le bordel. Sans parler des codes où il n'y a pas de procédures... Combien de codes sont commencés directement dans un évènement parce que "y a pas beaucoup à écrire", et puis au fil des mois les 20 lignes se transforment en 200 puis 2000 ... alors même que certains morceaux de code de l'évènement existent également ailleurs dans le programme.

Tout ça pour dire que finalement parler de la POO ici, c'est bel et bien parler des possibilités/impossibilités de Windev. C'est un manque énorme et malheureusement insoluble, c'était un mauvais choix de départ de la part de PCSoft.

[sphynxounet]

Pour la partie programmation (donc hors réglages d'ordre IHM) il est possible de faire pas mal de choses car finalement le WLangage est un mix de plusieurs langages. On retrouve une partie C : les fonctions du genre fOuvre, fPositionne, les pointeurs, et encore surement pleins d'autres choses que je ne connais pas en C.
Il y a aussi une petite partie objet avec les classes mais la gestion des types est POUR MOI de la fausse programmation orientée objet.
Un exemple tout simple si on écrit "fenêtre1.." Windev va nous proposer toutes les méthodes disponibles pour tous les types existant sous windev. Pour avoir fait un peu de VB.NET, la différence est flagrante dans le sens où en POO, si on appel un champ ou un type, on aura accès aux méthodes, paramètres et champs/types enfant héritant du champ ou du type parent.
Dans Windev il n'y a pas cette notion d'héritage ni de notion d'espace de noms. L'héritage dans les classes existe (encore heureux) mais pas dans les objets de notre programme.