Discussion :

[DonQuiche]

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 ?

[la.lune]

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.

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.

[gl]

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.

[Vlozer]

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

[LSMetag]

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.

[javan00b]

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.

[23JFK]

Bizarre, j'en suis à Dart Editor version 1.3.0.dev_00_00 (DEV) - Dart SDK version 1.3.0-dev.0.0

[sekaijin]

Re
Ce que je contest dans cette discussion c'est ça :

]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

[youtpout978]

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.

[anthyme]

Bon je precise deja je suis plus c# que java, mais j'ai fait pas mal de dev JS et typescript aussi.

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.

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.

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 ?

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

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

[Gugelhupf]

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,

[LSMetag]

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.

[anthyme]

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.

[anthyme]

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.

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.

[Gugelhupf]

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 ?

[sekaijin]

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

[anthyme]

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,

[DonQuiche]

...

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.

[la.lune]

Dart 1.2 Change l’expérience du développeur

Mais pourquoi pas Changer en mieux?

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

[sekaijin]

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