IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Dart Discussion :

Dart : l’alternative de Google à JavaScript prête pour la conquête du Web


Sujet :

Dart

  1. #121
    Expert confirmé Avatar de DonQuiche
    Inscrit en
    septembre 2010
    Messages
    2 741
    Détails du profil
    Informations forums :
    Inscription : septembre 2010
    Messages : 2 741
    Points : 5 459
    Points
    5 459
    Par défaut
    Citation Envoyé par sekaijin Voir le message
    je ne suis pas d'accord les languages supprotant l'héritage multiples sont pas légions. et lorsque tu a des objets qui sont issue de lib ou framwork tu ne peux pas les mettre dans une même collection typé c'est ainsi qu'on voit des List<Object> et autre truc car la seul classe commune est alors Object.
    Je trouve en général tes avis sur les technos web très intéressants mais concernant les langages typés il est clair que tu es à côté de la plaque. Des List<Object> je n'en rencontre jamais parce qu'on n'a pas besoin de listes d'objets hétérogènes, ou alors très rarement. Et si vraiment tu as besoin de faire ça (une fois tous les cinq ans), alors le motif "adaptateur" est là pour ça.

    Les seules fois où le typage statique me met inutilement des bâtons dans les roues, c'est relatif aux types paramétrés. Et encore c'est parce que je fais beaucoup de C# et que les types paramétrés y sont rudimentaires.

    je ne comptes pas le nombre de CastException que je vois passé sur le SI dans des produit à plusiers centaine de milliers d'euros lorsque ce n'est pas des nombres à plus de 6 chiffre.
    Là aussi je n'en rencontre jamais alors peut-être l'application a t-elle justement été conçue par quelqu'un qui, comme toi, est davantage familier des typages dynamiques et en adopte les façons de faire.
    Par ailleurs s'il y a erreur sur le type de donnes attendu, mieux vaut que ça te bondisse tout de suite à la tronche avec une exception que de voir le truc accepté en douce pour créer un bug tris kilomètres plus loin.

    une réalié au quotidient pas le choix la seule classe qui est capable de servir de base commune c'est Object.
    certaines des lib fournissent la méthode dont j'ai bessoin d'autre pas. les classe sont final impossible de les dérivers. impossible même si on pouvait des dériver de faire en sorte que la lib produise des objets dérivés elle n'est pas là pour ça. impossible donc d'avoir un moyen d'être sur d'avoir la même méthode partout.
    impossible de faire un traitement simple en parcourant les objet et en appliquant sur chacun une methode. du coup on caste on fait de s méthode utilitaire etc.
    on pisse du code.
    Apparemment tu parles d'un cas particulier et je te garantis qu'il est très particulier. Encore une fois peut-être auriez-vous mieux fait de faire un simple adaptateur au début.

    Pourquoi tant de language lève les contrainte de classes ? pourquoi tant de language joue avec des mécanisme d'introspection ? pourquoi voit-on fleurir les injection de byteCode ?
    Quoi, les besoins de métaprogrammation n'existent pas avec les langages dynamiques ? Si tu souhaites logger tous les appels pour les besoins du débogage, tu y penses très fort et ça se produit, ou alors tu mets en place une plomberie qui va modifier tes instances à la volée ?

    Parfoit les classes bien rigides sont des contraintes trop fortes.
    Je n'ai pas dit toujours, j'ai dit parfois.
    Tout à fait. Et l'absence de contraintes n'est pas toujours une bonne chose non plus.

    Par contre plus le projet est gros, plus le typage statique est utile. C'est à ce besoin que répond TypeScript.

    et lors on est confromté quotidiennement à ce genre de difficultés où on fini par pondre des centaines de lignes pour 1 appel de méthode ont change de méthode de travail et on prends des outils qui ont d'autres avantages pour d'autres usages avec des façons de travailler différents.
    Je pense vraiment que vous avec un très gros problème d'architecture.

    biensur les nom des champs ne sont pas homogènes c'est donc des centaines de lignes à écrire. alors qu'avec un langage plus souple comme js une boucle sur tous les membres de l'objet une map qui traduit le nom du champ une autre les valeur et
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    out[translateNom[membre] = translate[origValue]
    en 3 ligne et une table de paramètre c'est fini pour toute les classes.
    efficacité des classes 30 x 100 lignes de code java face à 3 lignes de js.
    Autrement dit en JS vous implémentez un pseudo-adaptateur, alors qu'en Java vous gérez tous les cas manuellement à chaque fois. A nouveau pourquoi ne pas avoir mis en oeuvre ce motif ?

  2. #122
    Membre chevronné
    Avatar de la.lune
    Homme Profil pro
    Directeur Technique
    Inscrit en
    décembre 2010
    Messages
    544
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Comores

    Informations professionnelles :
    Activité : Directeur Technique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : décembre 2010
    Messages : 544
    Points : 2 073
    Points
    2 073
    Par défaut
    Citation Envoyé par anthyme Voir le message
    Ton exemple n'est pas bon, justement dans un langage typé avec une architecture correct on fait pas de test d'instanceOf.
    On sait partout où l'on est le type des éléments et on peut donc appeler la méthode car le compilateur nous a assuré qu'on pouvait le faire
    Bon je ne partage pas le même avis sur istanceof, car même dans les lagunages fortement typés, le moment d’héritage on ne peut pas se permettre de faire un cast sur un objet de type de la classe mère, dans le moment où on est pas sûr que l'objet qui sera passé sera bien sûr l'objet contenant la méthode de la classe fille voulue. A part le fait d'appeler la méthode qui est défini dans la classe mère redéfini en calasse fille, dans le cadre de polymorphisme. Dans tous les langages objets le compilateur est incapable de connaitre le type de objet fille qu'on va appeler, d'où un test avant de faire le casting.

    Citation Envoyé par DonQuiche Voir le message
    Je trouve en général tes avis sur les technos web très intéressants mais concernant les langages typés il est clair que tu es à côté de la plaque. Des List<Object> je n'en rencontre jamais parce qu'on n'a pas besoin de listes d'objets hétérogènes, ou alors très rarement. Et si vraiment tu as besoin de faire ça (une fois tous les cinq ans), alors le motif "adaptateur" est là pour ça.
    Et il n'est pas toujours question de List<Object> mais d'un concept bien connu qui ne s'applique pas forcement sur la classe Object, mais dès que les contraintes de travailler avec des objets filles, en manipulant des objet typés de la classe mère, le problème se pose et l'oublie de ce test fait déjà l'objet un bug même si ça ne se manifeste pas à notre vu. Je me demande comment réaliser des architectures et des conception de qualité utilisant des design pattern et s'assurer qu'il n y a pas de bugs de casting quelque part, si on jette l'option du test sur instanceof.

    A moins de développer une application qui n'exploite pas fortement les conceptions objets.

  3. #123
    gl
    gl est déconnecté
    Rédacteur

    Homme Profil pro
    Inscrit en
    juin 2002
    Messages
    2 165
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Isère (Rhône Alpes)

    Informations forums :
    Inscription : juin 2002
    Messages : 2 165
    Points : 4 605
    Points
    4 605
    Par défaut
    Citation Envoyé par la.lune Voir le message
    Je me demande comment réaliser des architectures et des conception de qualité utilisant des design pattern et s'assurer qu'il n y a pas de bugs de casting quelque part, si on jette l'option du test sur instanceof.
    Comment ?

    Déjà en commençant par comprendre ce qu'est la substitution et le LSP et donc en arrêtant de faire hériter (publiquement dans les langages qui font la distinction) tout de n'importe quoi. Ça élimine un bon paquet de cas (et d'ailleurs ce n'est pas tant d'utilisations d'instanceof pour prévenir les bugs de cast que d'utilisations de cast dont on ne devrait pas avoir besoin) et évite au passage pas mal d'autres déconvenues.

    Ensuite en arrêtant de se focaliser sur le seul outil qu'est l'objet. Oui il y a des cas où un polymorphisme paramétrique convient mieux, où on ressent le besoin d'une approche fonctionnelle ou à prototype, où l'introspection correspond à ce que l'on souhaite faire, où.... Et, pour revenir aux propos de sekaijin, c'est aussi dans ces cas que je comprends l'intérêt de pouvoir avoir parfois un peu de typage dynamique (et pourtant je préfère de loin le typage statique mais parfois c'est un vrai point de blocage) agrémenté d'un soupçon de duck typing.


    Les seuls cas [1] où je comprends l'utilisation d'un instanceof ou d'une construction similaire et du cast qui va suit c'est pour "émuler" un mécanisme particulier (dynamisme, multi-dispatch) dans un langage où je n'en dispose pas. Mais ça reste de l'ordre de l'exception[2].





    [1] Enfin non, j'ai un autre cas : l'historique. Quand tu arrives sur un projet avec des héritages improbables et une utilisation massive de ce type de construction.
    [2] Ce qui en fait malgré tout un outil fort utile et intéressant.

  4. #124
    Membre habitué
    Profil pro
    Étudiant
    Inscrit en
    juillet 2009
    Messages
    56
    Détails du profil
    Informations personnelles :
    Âge : 32
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : juillet 2009
    Messages : 56
    Points : 163
    Points
    163
    Par défaut
    Personnellement après avoir essayé les deux, je porte beaucoup plus d'espoir en dart qu'en TypeScript, meme si dans l'immediat, j'espere que l'un ou l'autre prendra le dessus sur le js brut...

    Je ne connais pas le javascript... En tout cas tout juste assez pour faire le cake sur des page web avec JQuery, mais j'ai énormément de mal a apprécier ce langage... Ok, à chaque fois que j'ai eu à l'utiliser, j'ai souvent été surpris de élégances de certaines de ses syntaxes, mais le constat et là: si je n'ai aucun problèmes pour lire du javascript, je dois sans arrêt plus ou moins "réapprendre le langage" pour en ecrire... La faute selon moi à un certain manque de rigueur/ une trop forte flexibilité dans l'ecriture (et je dis pas ça forcement pour le typage dynamique, les signature de fonction à rallonge ou encore les fonctions anonymes imbriquées sans fin)...

    Pour tout dire, je n'ai pas eu la chance d'avoir pu suivre les étapes de l'evolutions du js, pourtant, j'ai l'impression de subir le poids de son age à chaque utilisation...
    Et cela dès l'apprentissage... Je me souviens qu'il y a encore quelque années, on nous donnait un alert('Hello world!'); en guise de première instruction... C'est assez représentatif du problème du js je trouve... Et c'est ce qui me donne cette impression que le js est construit sur des fondations instables...

    C'est peut etre une impression complètement fausse.... Mais c'est qui me donne envie de miser sur le Dart (qui part de 0) plutot que sur Typescript qui se content d'etre simplement une surcouche des-dites fondations.
    Dart voit beaucoup plus loin, pour moi ca n'a pas vraiment de sens de le comparer avec TS, car il ne s'agit pas ici de simplement typer le js (d'ailleurs en production, le dart ne fait aucune verif) mais il s'agit surtout de penser directement le langage pour comment il sera utiliser demain (scalable, concurent)...
    Et à ce titre, j'estime que Dart evoluera plus rapidement que Typescript/Javascript en plus d’implémenter nativement l’interprétation de certaines features qui ne seront qu'émulées en js...

    Et puis, sans vouloir stigmatiser Microsoft, je fais plus confiance à Google pour promouvoir une technologie web open source...

  5. #125
    Expert confirmé

    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    juillet 2009
    Messages
    1 030
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : juillet 2009
    Messages : 1 030
    Points : 4 121
    Points
    4 121
    Par défaut
    Un excellent article, même s'il date un peu : http://smthngsmwhr.wordpress.com/201...nd-typescript/

    En gros, ce que je retiens, c'est que je vais complètement délaisser Javascript et cie pour TypeScript ET Dart.


    - TypeScript est une superstructure comprenant JS, dotée des caractéristiques de nos langages actuels et d'un typage statique optionnel. Il est donc extrêmement avantageux dès lors qu'on se conforme à l'Ecmascript. Apprendre TypeScript, c'est finalement faire un code compatible JS (et autres langages dérivés), facilement compilable dans ce langage, clean. De plus, tout JS que l'on trouvera sur notre chemin sera facilement transposable en TypeScript et reprenable par ce biais. On est en gros dans ce que devrait être JS de nos jours, en suivant l'évolution d'Ecmascript. Sans oublier l'utilisation des Frameworks et librairies JS existants et l'adaptation parfaite à Visual Studio pour des projets .NET.

    - Dart sera sûrement plus confortable pour beaucoup, est beaucoup plus performant, y compris le Javascript généré qui est ultra optimisé même si très complexe (c'est pour ça qu'il peut surpasser du JS natif fait par des non experts en JS). Il est plus proche du paradigme des langages serveurs (c'est d'ailleurs aussi un langage serveur) et permet d'éviter totalement la syntaxe JS qui possède quelques écueils. Pour moi, le fait que le Javascript généré soit très compliqué (et minifié) est une sécurité supplémentaire sachant que n'importe qui peut voir les sources JS. Dart part sur des bases nouvelles et évolue très vite, grâce à toute une communauté qui participe activement à son développement via un bugtracker publique. Il ne s'encombre pas d'un historique parfois freinant comme JS, invention d'une seule personne finalement.

    Je ne mettrais pas un des "langages" devant l'autre. Chacun possède ses points forts et points faibles et conviendra suivant les situations. TypeScript est une valeur sûre, pérenne. Dart est un choix plus audacieux, mais qui peut être très profitable si on a une idée claire du projet sur le long terme.

    Voila. Et merci à anthyme et Developpez.com pour m'avoir encouragé à me documenter sur TypeScript, qui risque de me réconcilier (un peu) avec JS.

  6. #126
    Membre actif
    Profil pro
    Inscrit en
    avril 2009
    Messages
    182
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : avril 2009
    Messages : 182
    Points : 266
    Points
    266
    Par défaut
    Si tu veux developper en Javascript sans que sa coûte une fortune il te faut un gros stack d'une dizaine de librairie.

    Ya vraiment quelqu'un qui fait des gros projets scalable en vanilla javascript de nos jours avec un budget limité ?

    Faut etre serieux Dart c'est aussi bien structuré que Java, le temps de développement et la complexité sont reduit de beaucoup. C'est beaucoup mieux structuré que javascript et beaucoup + lisible pour n'importe quel programmeur qui fait de la POO sur un language qui n'a pas été architecturé en 10 jours !

    C'est une question de temps, quand les gens vont s'en rendre compte et que Dart aura pris en maturité... On risque de voir beaucoup + de gens l'utiliser.

  7. #127
    Membre émérite
    Profil pro
    undef
    Inscrit en
    février 2013
    Messages
    785
    Détails du profil
    Informations personnelles :
    Localisation : France, Lot (Midi Pyrénées)

    Informations professionnelles :
    Activité : undef

    Informations forums :
    Inscription : février 2013
    Messages : 785
    Points : 2 748
    Points
    2 748
    Par défaut
    Bizarre, j'en suis à Dart Editor version 1.3.0.dev_00_00 (DEV) - Dart SDK version 1.3.0-dev.0.0

  8. #128
    Expert éminent
    Avatar de sekaijin
    Homme Profil pro
    Urbaniste
    Inscrit en
    juillet 2004
    Messages
    4 186
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 57
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Urbaniste
    Secteur : Santé

    Informations forums :
    Inscription : juillet 2004
    Messages : 4 186
    Points : 9 105
    Points
    9 105
    Par défaut
    Re
    Ce que je contest dans cette discussion c'est ça :
    Citation Envoyé par Hinault Romaric Voir le message
    ]Dart 1.2 améliore l’expérience du développeur

    Entre Dart et TypeScript ? Quelle approche vous semble la meilleure pour combler les faiblesses de JavaScript ?
    Dart 1.2 Change l’expérience du développeur

    Entre Dart et TypeScript ? Quelle approche vous semble la meilleure pour une autre approche du développement web ?


    A+JYT

  9. #129
    Expert confirmé

    Homme Profil pro
    Développeur .NET
    Inscrit en
    novembre 2010
    Messages
    2 054
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : novembre 2010
    Messages : 2 054
    Points : 4 182
    Points
    4 182
    Par défaut
    Je pense qu'il y a la place pour plusieurs concurrents, côté serveur on a le choix d'une infinité de langage alors que côté client on est cantonné au JS.
    Si on peut avoir plusieurs solution capable de cohabiter pourquoi pas au lieu d'avoir le monopole d'un seul langage.

  10. #130
    Membre éprouvé Avatar de anthyme
    Homme Profil pro
    Inscrit en
    mars 2004
    Messages
    1 559
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : mars 2004
    Messages : 1 559
    Points : 1 254
    Points
    1 254
    Par défaut
    Bon je precise deja je suis plus c# que java, mais j'ai fait pas mal de dev JS et typescript aussi.

    Citation Envoyé par sekaijin Voir le message
    je ne suis pas d'accord les languages supprotant l'héritage multiples sont pas légions. et lorsque tu a des objets qui sont issue de lib ou framwork tu ne peux pas les mettre dans une même collection typé c'est ainsi qu'on voit des List<Object> et autre truc car la seul classe commune est alors Object.
    et tu n'a pas le choix si tu vérifie pas tu part dans les choux.

    je ne comptes pas le nombre de CastException que je vois passé sur le SI dans des produit à plusiers centaine de milliers d'euros lorsque ce n'est pas des nombres à plus de 6 chiffre.
    Tu peux fermer les yeux mais si tu vérifie pas un jour ça te tombe dessus.

    jutilise plusieurs normes qui définissent dans leur dommaine une représentation d'un ensemble d'objets. je fait appel à plusieurs fournisseurs qui propose chacun une implémentation d'une des normes. mais moi je manipule des objets dans l'ensemble de ces normes
    une réalié au quotidient pas le choix la seule classe qui est capable de servir de base commune c'est Object.
    certaines des lib fournissent la méthode dont j'ai bessoin d'autre pas. les classe sont final impossible de les dérivers. impossible même si on pouvait des dériver de faire en sorte que la lib produise des objets dérivés elle n'est pas là pour ça. impossible donc d'avoir un moyen d'être sur d'avoir la même méthode partout.
    impossible de faire un traitement simple en parcourant les objet et en appliquant sur chacun une methode. du coup on caste on fait de s méthode utilitaire etc.
    on pisse du code.
    Ecoute pour moi ce n'est pas de la POO ni même de la bonne programation, il y a des pattern pour ca Adapter ou Bridge.
    Différentes implémentations de domaines complètements différents n’empêche pas une abstraction avec un contrat spécifique, si ce n'est "pas possible" c'est juste qu'il y a une erreur de conception.
    Ces casts, test d'instance, switch de comportements sont justes des anti patterns.

    Citation Envoyé par sekaijin Voir le message
    avec un typage dynamique on transmute son objet. on lui attache la méthode de son chox à la volée.
    Et bien je préfère mille fois l'encapsulation.

    Citation Envoyé par sekaijin Voir le message
    Pourquoi tant de language lève les contrainte de classes ? pourquoi tant de language joue avec des mécanisme d'introspection ? pourquoi voit-on fleurir les injection de byteCode ?
    Ces questions nous avancent pas beaucoup ... Pourquoi les derniers langages qui sortent ajoutent le concept de classe ?

    Citation Envoyé par sekaijin Voir le message
    Parfoit les classes bien rigides sont des contraintes trop fortes.
    Je n'ai pas dit toujours, j'ai dit parfois.
    [...]
    efficacité des classes 30 x 100 lignes de code java face à 3 lignes de js.
    au final en java avec un 10aine de lignes de code et en jouant avec l'introspection on passe outre les protect private et autre artifice des classes java et on fait le vrai boulot soit le smême trois lignes qu'en JS. mais pour y arriver il faut casser le principe même des classe.

    J'ai vu des truc monstrueux dans ma carrière.
    [...]
    En effet les langages dynamiques sont naturellement plus doués pour le mapping d'objets à signature similaire. Mais on peut totalement le faire avec la majorité des langages typés soit en réflexion soit avec des lib éprouvés pour cela.

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    OrderDto dto = Mapper.Map<Order, OrderDto>(order);
    Même pas besoin de boucle :p

    Citation Envoyé par sekaijin Voir le message
    et il y a des absurdité partout en javascript dans 90% des développements. voici que l'ontrouve.
    [...]
    Si on réfléchi comme en java i faudrait dériver la classe Element pour cet élément là. pour avoir un élément qui porte CES methode là et pas d'autres.
    C'est sur que si on fasait ça en java on aurait plus de 60% des classe qui n'auraient qu'une seul objet.
    Il suffit de ne pas penser classe mais prototype et ojet dynamique pour comprendre que l'objet de la classe Element peut recevoir toutes les méthodes tous les attributs dont il a besoin.
    Je n'ai pas bien compris ton cas, en tout cas en C# on a les méthodes d'extension qui permettent de rajouter une méthode à une classe existante, pourtant on est sur un langage typé.

  11. #131
    Modérateur
    Avatar de Gugelhupf
    Homme Profil pro
    Analyste Programmeur
    Inscrit en
    décembre 2011
    Messages
    1 311
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Analyste Programmeur

    Informations forums :
    Inscription : décembre 2011
    Messages : 1 311
    Points : 3 660
    Points
    3 660
    Billets dans le blog
    12
    Par défaut
    Citation Envoyé par anthyme Voir le message
    Ton exemple n'est pas bon, justement dans un langage typé avec une architecture correct on nfait pas de test d'instanceOf.
    On sait partout où l'on est le type des éléments et on peut donc appeler la méthode car le compilateur nous a assuré qu'on pouvait le faire
    Je ne suis pas tout à fait d'accord avec cette affirmation.
    En Java par exemple, un langage que je considère comme plutôt strict (fortement typé, utilisation de variable non initialisé rejeté à la compilation, pas de fonction globale, pas de goto etc...) et nous avons pourtant droit à la contravariance et au mot-clé instanceof.

    Exemple concret : considérons l'exemple d'un jeu de dame. Il existe 2 types de pion : les pions standard et les dames (les deux se déplacent différemment, mais sont des pions tout de même).
    Lorsqu'un pion arrive dans le camp adverse, il se transforme en dame.

    Alors 2 possibilités de créer ces pions :
    • Soit tu crées une classe Pion unique, avec un champ "type" (0: pion, 1:dame).
    • Soit tu crées une classe Pion et une classe Dame (qui héritent d'une classe AbstractPion par exemple), et tu fais la différence avec instanceof.


    Personnellement, je préfère la seconde option, car elle apporte une meilleure lisibilité au code, ne serait qu'au niveau de l'instanciation des objets et des tests pour faire la différence.
    Par contre si je devais créer ce jeu en C++, j'opterais pour la 1ère option, à défaut d'utiliser dynamic_cast ...


    Cordialement,
    N'hésitez pas à consulter la FAQ Java, lire les cours et tutoriels Java, et à poser vos questions sur les forums d'entraide Java

    Ma page Developpez | Mon profil Linkedin | Vous souhaitez me contacter ? Contacter Gokan EKINCI

  12. #132
    Expert confirmé

    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    juillet 2009
    Messages
    1 030
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : juillet 2009
    Messages : 1 030
    Points : 4 121
    Points
    4 121
    Par défaut
    Citation Envoyé par 23JFK Voir le message
    Bizarre, j'en suis à Dart Editor version 1.3.0.dev_00_00 (DEV) - Dart SDK version 1.3.0-dev.0.0
    C'est parce que, comme moi au début, tu as pris le Bundle Dart de la branche DEV. Ce qui peut être normal si tu as commencé à tester Dart avant la version 1.0.
    Si tu le retélécharges depuis la page d'accueil tu devrais avoir celui de la branche STABLE.

  13. #133
    Membre éprouvé Avatar de anthyme
    Homme Profil pro
    Inscrit en
    mars 2004
    Messages
    1 559
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : mars 2004
    Messages : 1 559
    Points : 1 254
    Points
    1 254
    Par défaut
    Citation Envoyé par LSMetag Voir le message
    Et merci à anthyme et Developpez.com pour m'avoir encouragé à me documenter sur TypeScript, qui risque de me réconcilier (un peu) avec JS.
    De rien, je trouve ton analyse très pertinente. C'est bien les 2 termes que je cherchais : sécurité vs audace.

  14. #134
    Membre éprouvé Avatar de anthyme
    Homme Profil pro
    Inscrit en
    mars 2004
    Messages
    1 559
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : mars 2004
    Messages : 1 559
    Points : 1 254
    Points
    1 254
    Par défaut
    Citation Envoyé par Gugelhupf Voir le message
    Je ne suis pas tout à fait d'accord avec cette affirmation.
    En Java par exemple, un langage que je considère comme plutôt strict (fortement typé, utilisation de variable non initialisé rejeté à la compilation, pas de fonction globale, pas de goto etc...) et nous avons pourtant droit à la contravariance et au mot-clé instanceof.
    C'est pourtant l'avis des personnes les plus pointus en POO.

    Citation Envoyé par Gugelhupf Voir le message
    Exemple concret : considérons l'exemple d'un jeu de dame. Il existe 2 types de pion : les pions standard et les dames (les deux se déplacent différemment, mais sont des pions tout de même).
    Lorsqu'un pion arrive dans le camp adverse, il se transforme en dame.

    Alors 2 possibilités de créer ces pions :
    • Soit tu crées une classe Pion unique, avec un champ "type" (0: pion, 1:dame).
    • Soit tu crées une classe Pion et une classe Dame (qui héritent d'une classe AbstractPion par exemple), et tu fais la différence avec instanceof.


    Personnellement, je préfère la seconde option, car elle apporte une meilleure lisibilité au code, ne serait qu'au niveau de l'instanciation des objets et des tests pour faire la différence.
    Si tu utilises correctement l’héritage il n'y a aucune raison de faire d'instanceOf.
    Un exemple rapide : pour savoir si tu as le droit de te déplacer tu fais un méthode bool CanMove(int x, int y) sur la classe pion tu renvois true seulement pour des coordonnées en diagonale vers l'avant à une case mais l’implantation de la dame donne true pour les diagonales a n'importe quel nombre de case vers l'avant et l’arrière.
    Quand l'utilisateur veut bouger ce pion il appel juste la méthode CanMove(x,y). Il ne faut surtout pas qu'il switch sur des types pour faire des comportements.
    D'ailleurs j'aurais plutôt tendance à faire un pattern strategy (abstract MovementStrategy avec DameMovementStrategy et PionMovementStrategy) pour ne pas perdre l'instance initiale du pion mais bon c'est du détail.

  15. #135
    Modérateur
    Avatar de Gugelhupf
    Homme Profil pro
    Analyste Programmeur
    Inscrit en
    décembre 2011
    Messages
    1 311
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Analyste Programmeur

    Informations forums :
    Inscription : décembre 2011
    Messages : 1 311
    Points : 3 660
    Points
    3 660
    Billets dans le blog
    12
    Par défaut
    La pièce sur ton damier arrive dans le camp adverse. Ce n'est pas la méthode canMove() et son implémentation via le pattern Strategy qui vont changer quoi que ce soit.
    Arrivé à cette case, si la pièce est de type pion, celle-ci se transforme en dame (sinon elle ne change pas d'état). Comment faire pour savoir si la pièce qui est arrivé dans le camp adversaire doit se transformer en dame ou non ?
    N'hésitez pas à consulter la FAQ Java, lire les cours et tutoriels Java, et à poser vos questions sur les forums d'entraide Java

    Ma page Developpez | Mon profil Linkedin | Vous souhaitez me contacter ? Contacter Gokan EKINCI

  16. #136
    Expert éminent
    Avatar de sekaijin
    Homme Profil pro
    Urbaniste
    Inscrit en
    juillet 2004
    Messages
    4 186
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 57
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Urbaniste
    Secteur : Santé

    Informations forums :
    Inscription : juillet 2004
    Messages : 4 186
    Points : 9 105
    Points
    9 105
    Par défaut
    Citation Envoyé par anthyme Voir le message
    Ecoute pour moi ce n'est pas de la POO ni même de la bonne programation, il y a des pattern pour ca Adapter ou Bridge.
    Différentes implémentations de domaines complètements différents n’empêche pas une abstraction avec un contrat spécifique, si ce n'est "pas possible" c'est juste qu'il y a une erreur de conception.
    Pour moi lorsque une classe qui m'est fournie par un acteur du maché comme ceci.
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    Class Toto {
      private a;
      private b;
     
      public getA() {...};
      public setA(a) {...};
      public getB() {...};
      public setA(b) {...};
     
    }
    Je suis peut être un vieux con qui ne veux pas comprendre la conception, mais je n'ai pas le choix je NE PEUX PAS FAIRE
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    obj = new Toto();
     
    foreach (member : obj.getMembers()) {
      // traitement sur un champ de l'objet
    }
    C'EST le principe même de la POO à base de classe que de l'INTERDIRE.

    du coup comme un con je dois faire pour chaque classes pour lequel je rencontre ce genre de difficultée.
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    Map maMap = new MAP();
    maMap.put("a", obj.getA());
    maMap.put("b", obj.getB());
    foreach (member : maMap) {
      // traitement sur un champ de l'objet
    }
    Et que vous preniez le problème par tout les bout lorsque la classe Toto NE VOUS APPARTIENT PAS et qu'elle à cette contrainte la seule et unique façon d'accéder à un membre c'est de passer par le getter. et c'est NORMAL vu que la POO à base de CLASSE a été concue pour ça.

    Ce n'est pas un problème de conception c'est uin problème de langage.

    Je pourais construire ma prope classe qui offre cette possibilité de parcour.
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    Classe TotoBis {
      Map maMap = new MAP();
     
      TotoBis (Toto obj) {
        maMap.put("a", obj.getA());
        maMap.put("b", obj.getB());
      }
     
      Map getMembers() {...}
    }
    Mais il suffit de regarder le code de cette classe pour comprendre que ça ne change rien à la donne. Il FAUT acéder aux getter l'or du DEV un à un pour allimenter la MAP.

    La seule et unique façon de pouvoir accéder au membres de façon itérative est de CASSER ce modèle de la POO classique.
    certain langages le permètent de façon plus où moins élégante. d'autre comme java propose l'introspection.
    Je devrais revoir ma conception pour obtenir une classe à moi et Redévelopper moi même des librairies lourdes industrialisées, normalicée certifiées.

    Puis il y a des langage qui CHOISSISSENT de ne surtout pas contraindre trop fortement les objets.
    c'est UN CHOIX tout aussi RESPECTABLE que la POO à base de CLASSE STATIQUES.

    Ce genre de situation qui pour vous est rarissime est mon lot quotidien. Dans un cas comme celui-ci répété à longueur de journée un langage plus souple est plus que bien venu c'est un gage de QUALITE, de ROBUSTESSE, d'EVOLUTIVITE, de PERENITE, c'est GAIN de TEMPS, d'ARGENT.
    Et ça demande comme pour tous language de MAITRISER les capaciter de sont outil.

    cela n'en fait ni un meilleur outil ni un moins bon. cela en fait un outil différent adapté à des usages différent. un outil capable de proposer des solution SIMPLE et ELEGANTE là où le typage fort et statique est INCAPABLE de proposer une solution.

    Au même titre qu'il y a un besoin dans le web d'un langage plus structures pour faire des appli. il y a dans le monde des grand secteur d'activité où l'information déstructures est le meilleurs gage de succes. et pour ces activitées utiliser un lagage dont les concepts sont aussi souple que de l'information est déstructurée est une bénédiction.

    A+JYT

  17. #137
    Membre éprouvé Avatar de anthyme
    Homme Profil pro
    Inscrit en
    mars 2004
    Messages
    1 559
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : mars 2004
    Messages : 1 559
    Points : 1 254
    Points
    1 254
    Par défaut
    Citation Envoyé par Gugelhupf Voir le message
    La pièce sur ton damier arrive dans le camp adverse. Ce n'est pas la méthode canMove() et son implémentation via le pattern Strategy qui vont changer quoi que ce soit.
    Arrivé à cette case, si la pièce est de type pion, celle-ci se transforme en dame (sinon elle ne change pas d'état). Comment faire pour savoir si la pièce qui est arrivé dans le camp adversaire doit se transformer en dame ou non ?
    Je te donne un exemple de mouvement de pièce pion vs dame, je peux te faire à l'arrache pour la transformation :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    class Piece {
    public Piece {
    this.MutationStrategy = new PionMutationStrategy(this); //a setter dans une factory mais bon c'est du quick and dirty
    }
    public void ArrivedInEnemyCamp() {
    this.MutationStrategy.ArrivedInEnemyCamp() 
    }
    }
     
    class PionMutationStrategy : PieceMutationStrat{
    public ArrivedInEnemyCamp(){ // ce code serait encapsulé dans une méthode "TransformPionToDame"
    this.piece.MovementStrategy = new DameMovementStrategy(); 
    this.piece.MutationStrategy =  new DameMutationStrategy();
    }
    }
     
    class DameMutationStrategy {
    public ArrivedInEnemyCamp(){
    //rien
    }
    }
     
    var piece = new Piece();
    //si condition amenant sur les case adverse
    piece.ArrivedInEnemyCamp()
    Bon j’espère que c'est lisible.

    Peut être qu'un pattern visitor serrait intéressant, à voir.

    Un objet c'est pas juste un conteneur de data qui traverse du code procédural.

    Bref c'est ça de la POO,

  18. #138
    Expert confirmé Avatar de DonQuiche
    Inscrit en
    septembre 2010
    Messages
    2 741
    Détails du profil
    Informations forums :
    Inscription : septembre 2010
    Messages : 2 741
    Points : 5 459
    Points
    5 459
    Par défaut
    Citation Envoyé par sekaijin Voir le message
    ...
    Mais pourquoi diable as-tu besoin d'accéder à un champ par une chaîne donnée à l'exécution ? (car si la chaîne est connu à la compilation on en revient au motif adaptateur).
    Et pourquoi as-tu besoin d'énumérer les membres ? (ce qui a priori n'est nécessaire que pour de la métaprogrammation ou de la génération dynamique de code - certes plus complexe avec un typage statique).
    Mais quand je vois le genre de code que tu montre en exemple, je me dis que quelqu'un a tenté d'enfoncer un carré dans un tour rond et qu'il y a encore une fois un pb d'archi.

    Au même titre qu'il y a un besoin dans le web d'un langage plus structures pour faire des appli. il y a dans le monde des grand secteur d'activité où l'information déstructures est le meilleurs gage de succes. et pour ces activitées utiliser un lagage dont les concepts sont aussi souple que de l'information est déstructurée est une bénédiction.A+JYT
    Je ne suis pas sûr qu'il faille un langage déstructuré pour analyser des données déstructurées. A priori les deux sujets me semblent découplés.

  19. #139
    Membre chevronné
    Avatar de la.lune
    Homme Profil pro
    Directeur Technique
    Inscrit en
    décembre 2010
    Messages
    544
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Comores

    Informations professionnelles :
    Activité : Directeur Technique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : décembre 2010
    Messages : 544
    Points : 2 073
    Points
    2 073
    Par défaut
    Citation Envoyé par sekaijin Voir le message

    Dart 1.2 Change l’expérience du développeur
    Mais pourquoi pas Changer en mieux?


    Citation Envoyé par sekaijin Voir le message
    Entre Dart et TypeScript ? Quelle approche vous semble la meilleure pour combler les faiblesses de JavaScript
    Entre Dart et TypeScript ? Quelle approche vous semble la meilleure pour une autre approche du développement web ?
    Tu veux supprimer le terme faiblaisses comme si JavaScript est parfait il n a aucune de faiblesse? .

  20. #140
    Expert éminent
    Avatar de sekaijin
    Homme Profil pro
    Urbaniste
    Inscrit en
    juillet 2004
    Messages
    4 186
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 57
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Urbaniste
    Secteur : Santé

    Informations forums :
    Inscription : juillet 2004
    Messages : 4 186
    Points : 9 105
    Points
    9 105
    Par défaut
    Citation Envoyé par anthyme Voir le message
    Je n'ai pas bien compris ton cas, en tout cas en C# on a les méthodes d'extension qui permettent de rajouter une méthode à une classe existante, pourtant on est sur un langage typé.
    en C# et Objective-C tu peux ajouter une méthode à une classe existante. en Javascript tu peux l'ajouter au prototype ou à l'objet.
    en JAVA tu peux pas.

    mais en javascript si tu écrit sous forme de pseudo code voila ce que font les développeur (sans le comprendre)
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    classe Main {
     
      static function clic1 () {}
      static function toto () {}
    }
    classe specialElement1 {
     
      function clic() { return Main.click2(); }
    }
    classe specialElement2 {
     
      function clic() { return Main.toto(); }
    }
    ensuite tout cela est instancié.

    on voit bien que c'est débile que les fonctions clic de specialElement1 et specialElement2 peuvent contenir le corps des messages.
    javascript permet de le faire sur les objets directement pourtant dans 90% des dev on continu à définir des fonctions globales

    dans navigateur les fonctions globales sont attachée à l'objet window. et lorsque on fait <tag id="t5" onclic="clic1();"> on crée en fait une méthode qui est attachée à l'objet tag dont le corps est clic1()l'équivalent de getElementById("t5").onclic=function() {clic1(); return true;}>sur cet exemple je disais simplement que JS est basé sur l'ajout dynamique de méthode. mais que beaucoup de développeur vont écrire leur méthode dans d'autres objets pour implicitement creer une méthode dans l'objet cible que ne sert à rien.

    A+JYT

Discussions similaires

  1. [JavaScript Console] Pour I E 6 ?
    Par Jean_Benoit dans le forum Général JavaScript
    Réponses: 3
    Dernier message: 26/06/2006, 15h30
  2. [Javascript] PB pour récupérer des valeurs !
    Par chaser_T dans le forum Général JavaScript
    Réponses: 1
    Dernier message: 19/04/2006, 11h26
  3. [Javascript] code pour boutton back
    Par jack_1981 dans le forum Général JavaScript
    Réponses: 3
    Dernier message: 21/01/2006, 00h04
  4. Javascript pour charger une page web depuis un menu déroulan
    Par tomguiss dans le forum Général JavaScript
    Réponses: 1
    Dernier message: 14/10/2005, 09h58
  5. [Javascript] variable pour accéder à element d'un formulaire
    Par aurelienalix dans le forum Général JavaScript
    Réponses: 3
    Dernier message: 25/08/2005, 11h50

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo