Publicité
+ Répondre à la discussion
Page 6 sur 20 PremièrePremière ... 234567891016 ... DernièreDernière
Affichage des résultats 101 à 120 sur 395
  1. #101
    Membre chevronné
    Avatar de bombseb
    Inscrit en
    juillet 2005
    Messages
    530
    Détails du profil
    Informations forums :
    Inscription : juillet 2005
    Messages : 530
    Points : 706
    Points
    706

    Par défaut

    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

  2. #102
    Expert Confirmé
    Profil pro
    Inscrit en
    mars 2005
    Messages
    1 682
    Détails du profil
    Informations personnelles :
    Âge : 32
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : mars 2005
    Messages : 1 682
    Points : 2 528
    Points
    2 528

    Par défaut

    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 :
    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 :
    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.

  3. #103
    Membre Expert
    Homme Profil pro
    Développeur informatique
    Inscrit en
    juin 2004
    Messages
    1 220
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juin 2004
    Messages : 1 220
    Points : 1 484
    Points
    1 484

    Par défaut

    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

  4. #104
    Membre Expert
    Profil pro
    Inscrit en
    février 2005
    Messages
    1 744
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : février 2005
    Messages : 1 744
    Points : 2 226
    Points
    2 226

    Par défaut

    Bonjour à tous,

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

    L'intervention pertinente de bombseb m'interpelle.

    Citation Envoyé par bombseb Voir le message
    [..]
    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.
    _

  5. #105
    Inactif
    Inscrit en
    février 2003
    Messages
    4 342
    Détails du profil
    Informations forums :
    Inscription : février 2003
    Messages : 4 342
    Points : 4 432
    Points
    4 432

    Par défaut

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

  6. #106
    Expert Confirmé
    Profil pro
    Inscrit en
    mars 2005
    Messages
    1 682
    Détails du profil
    Informations personnelles :
    Âge : 32
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : mars 2005
    Messages : 1 682
    Points : 2 528
    Points
    2 528

    Par défaut

    Citation Envoyé par Lo² Voir le message
    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.

  7. #107
    Membre Expert
    Avatar de mogwai162
    Homme Profil pro Patrick Catella
    Inscrit en
    janvier 2006
    Messages
    1 376
    Détails du profil
    Informations personnelles :
    Nom : Homme Patrick Catella
    Âge : 51
    Localisation : France, Vosges (Lorraine)

    Informations forums :
    Inscription : janvier 2006
    Messages : 1 376
    Points : 1 825
    Points
    1 825

    Par défaut

    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...
    Patrick Catella

    Je ne réponds pas aux messages privés si ceux ci suivent un sujet. Il est préférable pour tous de poursuivre la discussion dans le sujet d'origine.

    Je suis Concepteur développeur Windev (10 ans) et Windev mobile (4 ans) en recherche d'emploi. J'etudie toute proposition

  8. #108
    Membre à l'essai
    Inscrit en
    juin 2008
    Messages
    52
    Détails du profil
    Informations forums :
    Inscription : juin 2008
    Messages : 52
    Points : 21
    Points
    21

    Par défaut

    Citation Envoyé par mogwai162 Voir le message

    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" ?

  9. #109
    Invité régulier
    Inscrit en
    mai 2009
    Messages
    7
    Détails du profil
    Informations forums :
    Inscription : mai 2009
    Messages : 7
    Points : 8
    Points
    8

    Par défaut

    Bonjour

    Je pense que vous faites erreur sur ce sujet.

    Citation Envoyé par =JBO= Voir le message
    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

  10. #110
    Membre Expert
    Avatar de mogwai162
    Homme Profil pro Patrick Catella
    Inscrit en
    janvier 2006
    Messages
    1 376
    Détails du profil
    Informations personnelles :
    Nom : Homme Patrick Catella
    Âge : 51
    Localisation : France, Vosges (Lorraine)

    Informations forums :
    Inscription : janvier 2006
    Messages : 1 376
    Points : 1 825
    Points
    1 825

    Par défaut

    Citation Envoyé par harf18 Voir le message
    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.
    Patrick Catella

    Je ne réponds pas aux messages privés si ceux ci suivent un sujet. Il est préférable pour tous de poursuivre la discussion dans le sujet d'origine.

    Je suis Concepteur développeur Windev (10 ans) et Windev mobile (4 ans) en recherche d'emploi. J'etudie toute proposition

  11. #111
    Membre habitué
    Inscrit en
    juin 2008
    Messages
    122
    Détails du profil
    Informations personnelles :
    Âge : 28

    Informations forums :
    Inscription : juin 2008
    Messages : 122
    Points : 103
    Points
    103

    Par défaut

    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.

  12. #112
    Membre Expert
    Avatar de mogwai162
    Homme Profil pro Patrick Catella
    Inscrit en
    janvier 2006
    Messages
    1 376
    Détails du profil
    Informations personnelles :
    Nom : Homme Patrick Catella
    Âge : 51
    Localisation : France, Vosges (Lorraine)

    Informations forums :
    Inscription : janvier 2006
    Messages : 1 376
    Points : 1 825
    Points
    1 825

    Par défaut

    Citation Envoyé par N_Ron Voir le message
    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.
    Patrick Catella

    Je ne réponds pas aux messages privés si ceux ci suivent un sujet. Il est préférable pour tous de poursuivre la discussion dans le sujet d'origine.

    Je suis Concepteur développeur Windev (10 ans) et Windev mobile (4 ans) en recherche d'emploi. J'etudie toute proposition

  13. #113
    Expert Confirmé
    Avatar de Emmanuel Lecoester
    Profil pro Emmanuel Lecoester
    Inscrit en
    février 2003
    Messages
    1 491
    Détails du profil
    Informations personnelles :
    Nom : Emmanuel Lecoester
    Âge : 38
    Localisation : France, Nord (Nord Pas de Calais)

    Informations forums :
    Inscription : février 2003
    Messages : 1 491
    Points : 3 396
    Points
    3 396

    Par défaut

    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
    Emmanuel Lecoester
    => On recrute des rédacteurs WinDev

  14. #114
    Membre Expert
    Profil pro
    Inscrit en
    février 2005
    Messages
    1 744
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : février 2005
    Messages : 1 744
    Points : 2 226
    Points
    2 226

    Par défaut

    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_

    Citation Envoyé par _Azul_ Voir le message

    Je pense que vous faites erreur sur ce sujet.

    Citation Envoyé par =JBO= Voir le message
    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é.

    Citation Envoyé par _Azul_ Voir le message
    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.
    _

  15. #115
    Membre Expert Avatar de klbsjpolp
    Profil pro
    Inscrit en
    décembre 2008
    Messages
    1 065
    Détails du profil
    Informations personnelles :
    Localisation : Canada

    Informations forums :
    Inscription : décembre 2008
    Messages : 1 065
    Points : 1 300
    Points
    1 300

    Par défaut

    Citation Envoyé par =JBO= Voir le message
    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*).

  16. #116
    Membre Expert
    Profil pro
    Inscrit en
    février 2005
    Messages
    1 744
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : février 2005
    Messages : 1 744
    Points : 2 226
    Points
    2 226

    Par défaut

    Il est bien entendu que je cherche pas à polémiquer.
    Citation Envoyé par klbsjpolp Voir le message
    Citation Envoyé par =JBO= Voir le message
    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)

    Citation Envoyé par klbsjpolp Voir le message
    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*)»
    _

  17. #117
    Membre Expert Avatar de klbsjpolp
    Profil pro
    Inscrit en
    décembre 2008
    Messages
    1 065
    Détails du profil
    Informations personnelles :
    Localisation : Canada

    Informations forums :
    Inscription : décembre 2008
    Messages : 1 065
    Points : 1 300
    Points
    1 300

    Par défaut

    Citation Envoyé par =JBO= Voir le message
    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.

  18. #118
    Membre Expert
    Homme Profil pro
    Développeur informatique
    Inscrit en
    juin 2004
    Messages
    1 220
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juin 2004
    Messages : 1 220
    Points : 1 484
    Points
    1 484

    Par défaut

    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.

  19. #119
    Expert Confirmé Sénior Avatar de Marco46
    Homme Profil pro Marc
    Développeur informatique
    Inscrit en
    août 2005
    Messages
    1 868
    Détails du profil
    Informations personnelles :
    Nom : Homme Marc
    Âge : 33
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : août 2005
    Messages : 1 868
    Points : 4 455
    Points
    4 455

    Par défaut

    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.
    "Toute personne croyant qu'une croissance exponentielle peut durer indéfiniment dans un monde fini est soit un fou, soit un économiste."
    Kenneth E. Boulding

    "/home/earth is 102% full ... please delete anyone you can."
    Inconnu

  20. #120
    Membre éclairé
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    436
    Détails du profil
    Informations personnelles :
    Âge : 33
    Localisation : France

    Informations forums :
    Inscription : décembre 2007
    Messages : 436
    Points : 354
    Points
    354

    Par défaut

    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.

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •