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

JavaScript Discussion :

Où va-t-on avec JavaScript ? [Débat]


Sujet :

JavaScript

  1. #241
    Expert éminent
    Avatar de sekaijin
    Homme Profil pro
    Urbaniste
    Inscrit en
    Juillet 2004
    Messages
    4 205
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Urbaniste
    Secteur : Santé

    Informations forums :
    Inscription : Juillet 2004
    Messages : 4 205
    Points : 9 127
    Points
    9 127
    Par défaut
    Je pense que ça n'a pas de sens.

    Un des principaux avantage de JS est de pouvoir dynamiquement faire évoluer ses objets.
    Ajouter supprimer remplacer des méthodes et des membres.

    si vous passez au typage fort (contraint) pour rendre ce genre de chose utile
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    var fct;
     
    fct = function fct(value) {
        if (!(value instanceof Type)) {
            throw new Error('value must be an instance of Type');
        }
    };
    alors vous perdez cette fonctionnalité essentielle de javascript. car à quoi va vous servir de savoir que value est une instance de Type si l'objet a perdu ses membres.
    Si vous voulez pouvoir faire ça il est obligatoire que le langage interdise l'ajout/suppression/modification de membres ou de méthodes.

    Vous vous retrouvez alors comme avec les autres langages à base de class Statiques à devoir multiplier le code pour faire des choses très simples en JS.

    Je sais qu'on m'a mis sur le dos une étiquette anti classe statique. Il n'en est rien. J'utilise quotidiennement ces concepts.
    si vous représentez une personne dans votre système par une instance, les capacités de votre "objet" devraient suivre l'évolution de la dite personne. or un bébé n'a pas les mêmes caractéristiques qu'un vieillard.
    Avec un typage statique il faut créer de nouveaux objets à chaque fois que la personne évolue pour passer de Bébé à Enfant Ado Adulte etc.. mais la vie n'est pas ainsi. On reste toujours la même personne. Une nouvelle personne n'est pas créée quand on quitte l'enfance pour devenir un ado. De plus la transition est progressive, elle n'est pas la même pour tous les individus.

    JS est un langage qui permet de faire vivre ces objets en les faisant évoluer, chose que ne permet pas les langages avec un typage contraint et statique.

    Je ne juge pas l'un ou l'autre je pense simplement que les domaines d'application sont différents bien qu'il y ait des zones de recouvrement. Vouloir contraindre JS à devenir un langage à typage contraint et statique c'est signer son arrêt de mort. Il n'aurait alors rien à apporter. Il existe déjà beaucoup de langages dans ce domaine.

    Je pense par contre qu'il a la place pour d'autre langage embarqué dans le navigateur.
    La norme HTML le prévoyait et il y a eu vb par exemple dans IE.
    Il manque donc juste aujourd'hui un consensus pour adopter un langage de ce type dans le navigateur à côté de JS.

    A+JYT

  2. #242
    Futur Membre du Club
    Homme Profil pro
    Développeur Java
    Inscrit en
    Mars 2014
    Messages
    30
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 66
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java

    Informations forums :
    Inscription : Mars 2014
    Messages : 30
    Points : 9
    Points
    9
    Par défaut
    Citation Envoyé par sekaijin Voir le message
    Je pense par contre qu'il a la place pour d'autre langage embarqué dans le navigateur.
    La norme HTML le prévoyait et il y a eu vb par exemple dans IE.
    Il manque donc juste aujourd'hui un consensus pour adopter un langage de ce type dans le navigateur à côté de JS.
    Oui. Dans les temps anciens, Java accompagnait Javascript.

    Alors la question est : que penser des préprocesseurs tel que TypeScript ?
    J'ai lu que ces pseudos-langages avaient comme vocation d'ouvrir le chemin vers cet "autre langage embarqué" dont vous parlez.

  3. #243
    Membre éprouvé

    Profil pro
    Inscrit en
    Juin 2007
    Messages
    748
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2007
    Messages : 748
    Points : 1 022
    Points
    1 022
    Conception / Dev

  4. #244
    Expert éminent
    Avatar de sekaijin
    Homme Profil pro
    Urbaniste
    Inscrit en
    Juillet 2004
    Messages
    4 205
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Urbaniste
    Secteur : Santé

    Informations forums :
    Inscription : Juillet 2004
    Messages : 4 205
    Points : 9 127
    Points
    9 127
    Par défaut
    je ne pense pas
    mais en entreprise des chose comme
    sonatype
    ne sont pas rares en entreprise

    A+JYT

  5. #245
    Futur Membre du Club
    Homme Profil pro
    Développeur Java
    Inscrit en
    Mars 2014
    Messages
    30
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 66
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java

    Informations forums :
    Inscription : Mars 2014
    Messages : 30
    Points : 9
    Points
    9
    Par défaut
    Citation Envoyé par ascito Voir le message
    je ne pense pas
    Désolé, je voudrais une précision.
    Vous répondez à la question d'Ascito ou à la mienne ?

    Citation Envoyé par ascito Voir le message
    Non, je vous remercie infiniment de votre sollicitude, mais je ne me pose aucune question quant aux outils que je dois utiliser. Je programme en Javascript (Mais j'utilise aussi le C, Java, assembleur... quand j'en ai besoin. J'ai même programmé en Pascal )
    Je pose la question au sujet de TypeScript car il est commandité par un acteur majeur de l'informatique et risque de s'imposer dans les normes futures du Javascript (je suppose donc que cette question correspond au sujet)

    Le Javascript est très complet et me satisfait parfaitement. Le javascript est un langage qui possède des propriétés très intéressantes.
    Notamment l'absence de typage, qui n'est peut-être pas un oubli, mais la volonté de proposer un autre format de programmation que celui qui était répandu dans les années 80.

    Je regarde avec circonspection l'auteur du langage Pascal (qui était le fer de lance des langage 'typé' des années 80) manipuler du javascript.
    Je ne remet pas en cause l'idée de créer une passerelle entre Javascript et un langage typé dans le HTML5.

    Je voudrais connaître les avis des autres utilisateurs de Javascript au sujet de cette idée de passerelle, et de la façon dont elle est mise en oeuvre.

  6. #246
    Expert éminent
    Avatar de sekaijin
    Homme Profil pro
    Urbaniste
    Inscrit en
    Juillet 2004
    Messages
    4 205
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Urbaniste
    Secteur : Santé

    Informations forums :
    Inscription : Juillet 2004
    Messages : 4 205
    Points : 9 127
    Points
    9 127
    Par défaut
    je répondais @Ascito

    Pour moi typage statique et typage dynamique sont complémentaire.
    Et si je regarde les évolutions des langages il n'y a pas grand-chose de neuf depuis bien longtemps.

    Les langages à typage statique fort embarquent de plus en plus de techno pour les rendre plus dynamique ou collaborer avec des langages plus dynamiques. Et les langages dynamiques fleurettent avec les typages statiques.

    Mais ce n'est pas nouveau. TCL qui a eu son heure de gloire (il y a 20 ans et est toujours utilisé) est un langage Dynamique qui s'associe très facilement avec C/C++
    Aujourd'hui on voit apparaitre exactement la même association avec le couple Java/Ecmascript (nashorn dans java 8)

    Javascript s'inscrit directement dans cette approche. le langage (EcmaScript) fourni l'isfrastructure d'exécution et l'hôte fourni tout le reste. Dans le navigateur chaque appel à une méthode du navigateur crée ou invoque un objet développé avec un langage natif (généralement C++)

    Ce genre de besoin correspond à tous les langages de macro embarqués dans les Applications. Un langage interprété souple et concis associé à des objets natif.
    Ce qui est moins courant c'est l'approche de Rhino/Nashorn ou le langage embarqué à accès à toutes les classes du langage Hôte et non plus seulement quelques objets prédéfinis.

    Javascript arrive à un seuil. il a été définit pour faire quelques amélioration dans un page web (après sa naissance côté serveur) mais il sert de plus en plus à écrire de véritables application. J’ai déjà vécu ce phénomène avec les Shell Scripts. À une certaine époque bon nombre d'acteur ont commencé à utiliser sh comme langage de programmation pour faire de vrais appli et non plus seulement pour scripter quelques commandes. Cette approche c'est heuré au même problème que JS rencontre. À savoir le typage dynamique pour l'essentiel. Lorsque le développement de l'application prend de l'ampleur cela pose des difficultés. Et on a alors vu apparaitre des langages interprétés typé de façon plus statique pour répondre à ce besoin. On a vu aussi beaucoup d'acteur revenir vers des langages plus durs. Mais se posait alors d’autres difficultés comme la perte de souplesse pour certaines parties. Et c'est à ce moment-là que des langages dynamiques embarqué ont pris du poids.

    L'association de langage strict avec de langages plus souple est aussi vieille que l'informatique. LISP n'est quasiment jamais utilisé seul par exemple.

    A+JYT

  7. #247
    Futur Membre du Club
    Homme Profil pro
    Développeur Java
    Inscrit en
    Mars 2014
    Messages
    30
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 66
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java

    Informations forums :
    Inscription : Mars 2014
    Messages : 30
    Points : 9
    Points
    9
    Par défaut
    Citation Envoyé par sekaijin Voir le message
    le langage (EcmaScript) fourni l'isfrastructure d'exécution et l'hôte fourni tout le reste.
    C'est précisément au sujet cette partie que je m'interroge.

    Au sujet de l'interpréteur
    Quel impacte l'interprétation des léxèmes peut-il avoir sur le déroulement d'un script ?
    Ce traitement, qui peut être parfois inutile, est-il contournable ?
    (par exemple avec des portions compilées, à l'image des macros l'assembleur dans un script en C)

    Est-ce que l'EcmaScript est destiné à rester la seule norme de langage dans l'environnement HTML ?

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

    Informations professionnelles :
    Activité : Urbaniste
    Secteur : Santé

    Informations forums :
    Inscription : Juillet 2004
    Messages : 4 205
    Points : 9 127
    Points
    9 127
    Par défaut
    Pour se passer d'un interprète il faudrait que toutes les machines tous les navigateurs utilisent le même code binaire.

    À défaut et on le voit bien avec les applications de nos machine il faut créer autant de version que d'OS et de processeurs.
    Il devient vite évident que l'intérêt du navigateur est alors plus que douteuse.
    À quoi peut bien servir un client web quasi universel si on doit fournir autant de contenu que d'OS possible ?

    Reste donc l'approche de la machine virtuelle. Ce qui était le but de Java à l'origine. On compile dans un code intermédiaire reste à la VM de faire le reste.
    Là encore on voit bien que ce n'est pas toujours aussi simple.

    À cela s'ajoute le contexte. On n'est pas dans un cadre où l'in doit exécuter des applis dont le code fait du calcul intensif avec des temps de réponse contraints et fort.
    Une webapp se doit d'être réactive à l'échelle humaine de temps. Le calcul intensif, les traitements lours c'est pour le serveur. Le poste client doit lui assurer une bonne présentation et de l'a réactivité aux actions de l'utilisateur.

    La question à se poser est quel est l'impact de l'interprétation dans ce contexte. En tenant compte du fonctionnement de l'interprète. Aujourd’hui le parsing du code est infime en rapport du temps réseau. Ensuite le moteur JS compile le code à la volée et conserve la version compilé durant toute la vie de la session. Du coup soit on a une application qui est multi page et qui génère du js dynamiques sur le serveur et le navigateur ne peux mettre ce code source en cache et encore moi conserver la version compilé. Soit on a une application mono page avec tous le js dans des fichiers statique et le moteur peut utiliser le cache réseau et surtout le code compilé. Entre ces deux approches extrêmes je vous laisse imaginer toute les possibilités.
    Toujours est-il que si on se met dans la cadre idéal le temps de compilation devient marginal. Le moteur exécutant le plus souvent du code déjà compilé. Et plus on utilise l'appli plus ce temps se marginalise.
    Si on se met dans le pire des cas. Il est déjà difficile pour un humain de percevoir le pouillème de temps que représente la compilation dans l'exécution d'un code.
    Aujourd'hui les moteur JS ne fonctionnement pas sur le principe du ByteCode. ils utilisent des compilateur JIT qui produisent du code natif.

    Dans le cadre d'ihm web, JS est largement assez performant pour ne pas avoir à se poser des questions de compilation ou pas. Mais aujourd'hui de nouveaux usages du navigateur apparaissent et entre autre l'utilisation de rendu 3D de jeux et bien d'autre chose. Là on commence à effectivement se retrouver avec du calcul plus intensif coté client. Et se pose réellement le problème des performances pures. Ce qu'il faut comprendre c'est que passer du compilé à la volé au précompilé c'est gratter des ns ici ou là.

    Si je reprends les développements d'appli en shell. Aujourd’hui on ne se pose pas la question on fait du traitement lourd en C++ et on réserve le shell à l'adaptation à l'OS.
    Tout script sh peut être refait en C ou C++ il va gagner en perf.
    Mais quel gaint réel pour l'utilisateur ? Quelle complexité de dev ajoutée pour les développeurs ?

    JavaScript est compilé. Perdre cette capacité à s'exécuter "partout" cette facilité de mise en œuvre pour des nanosecondes, est-ce réellement un gain ?

    Mais on voit bien avec WebGL et tout un tas d’autres technos que les besoins s'étoffent.

    A+JYT

  9. #249
    Futur Membre du Club
    Homme Profil pro
    Développeur Java
    Inscrit en
    Mars 2014
    Messages
    30
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 66
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java

    Informations forums :
    Inscription : Mars 2014
    Messages : 30
    Points : 9
    Points
    9
    Par défaut
    Toutes ces explications sont très instructive (car très didactique ). Elles offrent un résumé intéressant de la situation actuelle, des orientations et des nouvelles contraintes qui émergent dans l'environnement HTML.

    Vos messages successifs permettent de préciser la situation. Et surtout la diversité des domaines abordés esquisse un plan d'ensemble cohérent; tout en conservant à l'esprit qu'il ne s'agit que d'exemples pour cet univers très riche.

    Vous m'avez conforté dans l'idée de continuer à travailler avec Javascript, mais je reste en éveil

    Merci pour ces éclaircissements

  10. #250
    Membre chevronné
    Avatar de la.lune
    Homme Profil pro
    Directeur Technique
    Inscrit en
    Décembre 2010
    Messages
    545
    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 : 545
    Points : 2 084
    Points
    2 084
    Par défaut
    Citation Envoyé par sekaijin Voir le message
    Si vous représentez une personne dans votre système par une instance, les capacités de votre "objet" devraient suivre l'évolution de la dite personne. or un bébé n'a pas les mêmes caractéristiques qu'un vieillard.
    Avec un typage statique il faut créer de nouveaux objets à chaque fois que la personne évolue pour passer de Bébé à Enfant Ado Adulte etc.. mais la vie n'est pas ainsi. On reste toujours la même personne. Une nouvelle personne n'est pas créée quand on quitte l'enfance pour devenir un ado. De plus la transition est progressive, elle n'est pas la même pour tous les individus.
    Tu fais comme si avec les lagunages à typage static on est bloqué pour pouvoir réaliser un truc pareil à évolution progressif, et tu mélange entre avoir un type static pour représenter une catégorie de personne une une fois déjà sérialisé et qu'on veut le dé-sérialiser pour lui donner une nouvelle catégorie. Avec l'héritage, on a toujours la même personne mais étendu.

    N'oublies pas que dans la vie courante on a des hommes et des objets concrets, on les vois, on a pas des variables qui les représentent, Le plus important pour la personne c'est son identité, tu es né ton acte de naissance reste le même, et il y a un ensemble de propriété qui sont connus en commun(taille, age, poids...).

    Quand je dois utiliser des variables(fiche à remplir pour le passage du concours de permis, le bac ou l'inscription à l'université) certes c'est la fiche qui me définit, c'est comme une variable et là on doit définir le contexte et les champs à remplir sont connus.

    Tout ce qui va évoluer passe par des listes(tes modules sur lesquels tu es inscrit, tes notes, ou la liste de tes délits dans ton casier judiciaire), venir définir un attribut à chaque inscription à un module serait du bordel.

    Ainsi, si au préalable je sais que mon programme va évoluer continuellement et que au cours du même programme je dois faire évoluer mes objets je n'ai pas qu'une seule technique avec les langages à typage static.

    Si je suis incapable de connaître la liste des attributs comme j'ai dis j'opte pour une liste dynamique d'objet/générique, sinon pour mieux faire j'utilise un map, qui me permet d'associer le nom de l'attribut avec la valeur.

    Et c'est l'objet lui même qui nous informe sur ses attributs dynamiques, je ne crée pas de nouveaux objet.

    Le problème avec ton cas en javascript, j'ai un type unique, donc si je viens consulter ton programme et je veux travailler je ne peux pas savoir qui sont les vieux et les ado, et je ne peux pas me permettre de demander un attribut que je en connais pas. Il faut consulter objet par objet jusqu'à se perdre par ce qu'on cherche la personne qui a des barbes

    Avec les langages à typage static en POO, j'ai aussi une technique plus intéressante si je veux toujours garder la même personne en mémoire mais ajouter des attributs, sans utiliser des listes, alors j'utilise patron de conception nommé Décorateur, à chaque fois je décore la même personne, avec des attributs et des méthodes.

    Le principe est simple pour celui qui veut le savoir : j'ai un objet possible d'être décoré et un objet décorateur alors tous les deux vont hériter d'un objet nommé composant et le décorateur aussi déclare un attribut de type composant en son interne. Donc si je crée un décorateur il prend un objet de type composant(donc un décoré), je peux déclaré autant de type de décoration qui vont hériter de décorateur, donc si b décore a, donc b reçoit a dans son constructeur, et j'ai un c qui veut décorer a, donc c reçoit b dans son constructeur car b aussi est un composant, et on peut enchaîner et on utilise des technique de récursivité dans les méthodes.

    Quand tu deviens ingénieur tu est diplômé ou expert confirmé senior, donc je te décore et je peux aussi connaître les personne ingénieur, les experts et les personne normales, au moins je connais mes décorations. Tu as reçu un trophée de developpez.com par ce qu'on a déjà défini c'est quoi le trophée donc un type de décoration défini. Et ce n'est pas un attribut propre à toi.

    Mais en js tu veux que le trophée soit un attribut propre à toi

  11. #251
    Expert éminent
    Avatar de sekaijin
    Homme Profil pro
    Urbaniste
    Inscrit en
    Juillet 2004
    Messages
    4 205
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Urbaniste
    Secteur : Santé

    Informations forums :
    Inscription : Juillet 2004
    Messages : 4 205
    Points : 9 127
    Points
    9 127
    Par défaut
    Tu fais comme si avec les lagunages à typage static on est bloqué pour pouvoir réaliser un truc pareil à évolution progressif
    Je n'ai jamais dis qu'avec les typage statique il n'y avait pas de solutions

    je dis que le typage dynamique, et la possibilité de changer dynamiquement un objet n'existe pas avec les typage statique et que donc il faut pour cela trouver des moyens pour représenter un objet évolutif ce qui en javascript s'écrit naturellement.

    je dis que dire que cette capacité est une tare est une erreur. c'est une force.

    et Je n'ai jamais dis que le typage statique n'était pas bien.
    j'ai dis que le typage dynamique offre une souplesse que le typage staique n'offre pas. au même titre que le typage statique offre des services que le typage dynamique n'offre pas.



    A+JYT

  12. #252
    Membre chevronné
    Avatar de la.lune
    Homme Profil pro
    Directeur Technique
    Inscrit en
    Décembre 2010
    Messages
    545
    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 : 545
    Points : 2 084
    Points
    2 084
    Par défaut
    Oui je suis d’accord dans la souplesse pour réaliser ce qu'on veut dans ce sens. Mais dire que c'est une force non, c'est du bidouillage, au prealable js n'a pas été fait pour de grosses programmes, du coup on bidouille et on souffre pour ça après, alors où est la force.

    Comment dire que c'est une force alors que ça ouvre aux développeurs la porte de pondre du code qui n'est pas forcement réutilisable, du code que seul celui qui l'a codé le comprenne.

    Ceux qui ont pensés aux langages à typage static non seulement ils se sont inspirés de ce qui passe dans la vraie vie, mais ils ont pensés que pour pouvoir avoir quelque chose de mieux simple à utiliser plus structuré, pour le present et pour le future il faut de la patience.

    Ce n'est pas par ce que Mercedes-Benz a déployé plus d'effort et temps pour implanter ses usines et utiliser plus de ressources que Renault qui utilise moins est mieux, possible que le temps qu'il passe pour pondre un véhicule est moins que le temps que Mercedes Benz passe.

    Bac+2, on développe déjà et Bac+3, on code encore mieux, Bace+5 on est ingénieur. Pour une bonne chose il faut faire mieux et un peu de patience.

    Toi tu veux dire à quoi ça sert un Bac+5 pour un simple développeur alors qu'avec un bac plus 2 je peux coder, donc plus de souplesse non? Pour moi js est comparé à une formation de bac+2 point barre.

    Pour faire des choses extraordinaires il faut encore percé dans des langages plus robustes qui permettent non seulement de faire des choses que js ne peut jamais faire(compilateur, manipulation de bit, multitâche,programmation fonctionnelle...) mas des programmes bien structurés et plus robustes pour une longue durée et réutilisables facilement, c'est pour cela qu'il faut de la rigueur dans la programmation, on peut pas tolérer des bêtises, si tu veux du sérieux bienvenue, si tu as peur de la rigueur au détriment de quelque chose plus robuste alors vas y dans javascript

    Le concept même de ce dynamisme sur les objets est contre nature même. Quand on fait des choses on doit les faire comme dans le monde naturel, quand un PC portable sort de l'usine il reste lui même, il est hors de question à ce que je pense lui ajouter un 2e écran, ou plus de RAM au dessus des places qui sont définis pour les barres de RAM. Quand on veut implanter un organe manquant à un homme ça nécessite une opération de chirurgie plus complexe.

    Javascipt veut que sur des objets sortie de l'usine on ajoute ce qu'on veut, modifier les API de tout le monde comme je veux, c'est du vol ça.

    Ou bien dire au prealable, ça ne sort pas de l'usine déjà fait, juste je le crée sans connaître ces composants de temps à autre je vais ajouter ce que je veux et les fonctionnalités que je veux et enfin tu as un objet que seul toi qui le comprend, non réparable s'il tombe en panne.

    Un objet en js (je m'excuse tu terme) je le compare une p*t qui n'a pas de mec spécifique à chaque fois il a un nouveau mec, donc plusieurs à la fois il doit définir un nouveau partenaire et garder ses cordonnées .

  13. #253
    Membre chevronné
    Avatar de la.lune
    Homme Profil pro
    Directeur Technique
    Inscrit en
    Décembre 2010
    Messages
    545
    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 : 545
    Points : 2 084
    Points
    2 084
    Par défaut
    sekaijin tu es expert dans le domaine et très ancien que moi, et tu sais parfaitement que si JavaScript était un langage compilé pour faire des applications bureau par exemple il serait le langage le plus vulnérable.

    Sécuriser son application serait la chose la plus complexe, voir impossible il faudrait repenser même le langage.

    Faire planter un programme javascipt ou le hacker est vraiment un jeu.

    Un objet en javascipt est très souple que sa vie est même mis en danger. Je crois que la comparaison que j'ai fais est mieux que le vrai cas d'un objet javascript.

    Un objet en JavaScript accepte à ce qu'il soit violé par tout le monde, il est content il ne dit rien, pas de concept d'encapsulation, rien n'est privé, même si je lui enlève des attributs qui définissent son existence il ne dit rien, donc je peux lui enlever son cœur et son cerveau c'est grave!!!

  14. #254
    Expert éminent
    Avatar de sekaijin
    Homme Profil pro
    Urbaniste
    Inscrit en
    Juillet 2004
    Messages
    4 205
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Urbaniste
    Secteur : Santé

    Informations forums :
    Inscription : Juillet 2004
    Messages : 4 205
    Points : 9 127
    Points
    9 127
    Par défaut
    Mais vous me prêtez des intentions que je n'ai pas.

    Je vais clore la discussion.
    Les procès d'intention ne mènent jamais à rien.

    Le fait que les langages à typage statique incluent de plus en plus de dynamismes et très probablement une grossière erreur que font tous les ingénieurs qui travaillent à l'évolution et l'élaboration de nouveaux langages.
    Vu que le dynamisme est selon vos dires une catastrophe.

    Les chercheurs et les scientifiques qui utilisent des langages interprétés pour leurs caractéristiques sont aussi des gens qui sont dans l'erreur et il faut absolument les ramener dans le droit chemin en supprimant les hérésies des langages qui ne sont pas dans la sacro-sainte norme enseignée comme étant le Saint-Graal à savoir les langages à typage statique à base de classe.

    Il est clair qu'il faut aller dans le sens de la pensée unique et ne surtout pas voir une force dans les caractéristiques d'un langage s'il s'écarte de la façon normalisée de penser.

    Je comprends qu'en agissant ainsi je suis entré dans une hérésie et que le monde de l'informatique va bientôt arrêter d'ajouter certaines de ces caractéristiques dans les langages à base de classes statiques.

    Je comprends que l'arrivée de Nashorn est une erreur monumentale de tous les ingénieurs de la planète qui oeuvre à faire évoluer Java.

    Je comprends que hors de la conception standardisée. Point de salut.
    Je comprends que les chercheurs en informatiques qui pondent et utilisent des langages dynamiques se sont tous fourvoyés depuis des décennies.

    Je vais continuer à utiliser les langages à typage statiques pour leurs forces dans les domaines où cela est une réponse pertinente à mes besoins.
    Je continuerais à être dans l'erreur monumentale en utilisant les caractéristiques des langages dynamiques pour mes besoins quand ces caractéristiques sont des réponses efficaces à mes besoins.

    Et je vais arrêter de vous dire que les deux approches ont des forces et des faiblesses et que ni l'une ni l'autre n'est supérieure. Je vais arrêter de dire qu’elles répondent à des besoins différents. Et je vais arrêter de dire qu'utiliser une de ces approches dans un domaine qui n'est pas le sien est une erreur de mon point de vue.
    Je vais arrêter de dire que ce que propose facilement une des deux approches est difficile dans l'autre et vice-versa.

    J'ai bien compris que EcmaScript est un langage pourri bon à jeter qu'il ne faut surtout pas l'utiliser pour ce qu'il sait faire. Et qu'il vaut beaucoup mieux produire des architectures complexes à base de langage statique en utilisant des conceptions normalisées, et ce même si cela n'est pas une réponse efficace au besoin.

    Je vais m'empresser de dire à tous les ingénieurs système qu'il faut qu'ils arrêtent d'utiliser les Shell script et utilisent au plus vite leur compilateur C/C++ pour leur besoin. Qu'ils sont tous depuis les années 50 dans l'erreur la plus monumentale ! Parce qu’utiliser le Shell script pour faire une application de bureau implique de trop gros problèmes, ils ne doivent surtout pas l'utiliser dans leur domaine où ça répond parfaitement à leur besoin.

    Alors je le dis une dernière fois. Les deux approches ont leurs forces et leurs faiblesses, les deux approches ont des domaines de prédilection. Et juger une caractéristique de l'un en se plaçant dans le domaine de l'autre n'en fait pas une mauvaise approche.

    J'espère que pour une fois on lira ce que je dis et non ce qu'on veut me faire dire.
    Je me refuse à dire que les langages à base de classe statiques sont de mauvais langages.
    Je me refuse à dire que ces langages n'offrent pas de solutions.

    Ceci sera ma dernière intervention sur le sujet. Car il est clair, que la réponse à la question
    Où va-t-on avec JavaScript ?
    est
    On doit le faire disparaitre au plus vite.


    A+JYT

  15. #255
    Membre chevronné
    Avatar de la.lune
    Homme Profil pro
    Directeur Technique
    Inscrit en
    Décembre 2010
    Messages
    545
    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 : 545
    Points : 2 084
    Points
    2 084
    Par défaut
    Il faut bien comprendre mon but et ne déduit pas de mon message ce que je n'ai pas dis. Mon message n'a rien n'avoir avec l'abadon de Javascript ni la suppression des languages interpreté ou dynamiques.

    En premier lieu tu as apporté un concept de comparaison comme quoi javascript est le mieux adapté pour se conformer au monde réel, et ben je t'ai dis que non, et je t'ai montré qu'au contraire un objet dans le monde réel est quelque chose de static.

    En 2e lieu tu défends comme quoi le concept de dynamisme sur les objets en javascript est une force au lieu de le réduire en une simple souplesse, eh ben saches qu'on code tous en javascript et on sait que cela ne sert que sur le gain en productivité et ça s’arrête là. Alors n'avances pas ce qui est le contraire car si on veut regarder au fond des choses, tu veux transformer une faiblesse en force.

    Citation Envoyé par sekaijin Voir le message
    Le fait que les langages à typage statique incluent de plus en plus de dynamismes et très probablement une grossière erreur que font tous les ingénieurs qui travaillent à l'évolution et l'élaboration de nouveaux langages.
    Vu que le dynamisme est selon vos dires une catastrophe.
    Tu mélanges entre typage dynamique des variables, dynamisme grâces aux expression lambda, réflexion... d'un côté et le dynamisme sur les objet grâce au prototypage de l'autre côté , c'est ça le sujet, il faut bien lire ce que j'ai écris, voci mon message intégral
    Citation Envoyé par la.lune Voir le message
    Le concept même de ce dynamisme sur les objets est contre nature .
    PHP, Python, Ruby, sont des langages à typage dynamique mais pour ce qui est des objets ils sont basés sur des classes, c'est la logique d'un objet, ça sous entend déjà quelque chose bien défini Il est hors de question sur ces langages à ce que j'enlève un attribut ou que je lise un attribut privé ou protégé là où je ne peux pas, et les objets sont bien sûr stockés sur des variables.
    Citation Envoyé par sekaijin Voir le message
    Les chercheurs et les scientifiques qui utilisent des langages interprétés pour leurs caractéristiques sont aussi des gens qui sont dans l'erreur et il faut absolument les ramener dans le droit chemin ....
    Qui t'a dis qu'ils sont dans l'erreur, on t'as dis que tout simplement que si le besoin de typage satatic basé sur des classe se presente c'est pour des besoins de programmes bien structiré robustes, maintenables et sécurisé, et extensibles, donc si tu veux reduire l'effort pour le bsoin en une faiblesse c'est passer à coté de la plaque. Et si des scientifiques utilisent des languages pareils sache bien que leur applis ne sont pas destinés au grand public, aucun risque.

    Et c'est que tu présente c'est un cas vraiment rare les rechercheurs et scientifiques cherchent des langages compilés, pour des raison de performance, et multitâche, alors ceux là que tu cite sont loins des gens qui font des programmes parallèles et qui ont besoin aussi aux supercalculateurs.

    Citation Envoyé par sekaijin Voir le message
    Il est clair qu'il faut aller dans le sens de la pensée unique et ne surtout pas voir une force dans les caractéristiques d'un langage s'il s'écarte de la façon normalisée de penser.
    Je comprends qu'en agissant ainsi je suis entré dans une hérésie et que le monde de l'informatique va bientôt arrêter d'ajouter certaines de ces caractéristiques dans les langages à base de classes statiques.
    Pensée unique non, mais pas transformer une faiblesse en force, cadrons les chose tels qu'ils sont et ouvrons un peu les yeux, définissons les choses avec les bon termes.

    Les programmes géantes qui sont devants nous sont codés avec des languges à typage static qu'ils soient objet ou non: nos OS, nos compilateurs, nos navigateurs, nos machine virtuelles....

    Tu oses accuser ces lagunages de faiblesse par ce qu'ils n'ajoutent pas la notion de prototypage et que javascript est le plus fort avec ça? Quel troll ça!! Vraiment le monde à l'envers.

    Ceux là qui ont même conçu javascript depuis 1995 (javascrit est le fruit de Netscape et Sun actuellement sous Oracle), ils ont vu cette faiblesse tous ces années et ils attendaient sekaijin pour leur dire qu'ils avaient tort alors que c'est eux même les experts qui ont conçu ça.

    Dis moi ce que je ne peux pas réaliser avec les langages à typage static basés sur des classes? Tu ne cesses de dire que chacun à ses faiblesses et ses avantages: grosse troll encore.

    Montres moi la seule limite devant moi qui me bloquerait d'atteindre mon but ou me défendre d'un mal avec les langages à typage static basés sur des classes et qui embarquent des API plus matures écrites bien sûr sur ses langages? Où est la faiblesse alors?

    Pour moi une faiblesse c'est de ne pas pouvoir réaliser quelque chose qu'ont veut, javascript est parmi les candidats, je peux tuer ces objets comme je veux, j'accède à tout, en tant que développeur j'aurais aimé plus de sémantique dans mes instructions, que le langage m'aide à détecter mes erreurs. J'aurais aimé que mon programme JavaScript ne soit pas piraté, ou volé car j'ai déployé tant d'effort, je ne peux pas.

    Mais cela ça ne constitue pas une catastrophe, car en partie le contexte de javascript définit n'est pas fait pour certaines choses et mes codes javascript marchent très bien et j'arrive à atteindre mon besoin spécifique avec, pourquoi veux-tu toujours mélanger, que lorsqu'on discute sur ce qu'il faudrait améliorer, tu as tendance toujours à dire "Eh ne voyez pas telle fonctionnalité ce n'est pas toujours beau", ah bon tu dis ça toi alors que javascrpt si on veut le comparer on ne peut même pas comparer.

    Les sucres syntaxiques et les souplesses fournis pour les développeurs, les débutants, ceux qui apprennent par bidouillage ou ceux qui viennent d'un autre monde pour ne pas casser leurs habitudes n'ont en rien sur la force d'un langage, on simplifie les choses mais ça ne veut pas dire qu'on souffre d'une faiblesse.

    En quoi une tablette est plus fort qu'un PC? Est ce par ce que la tablette est plus pratique qu'un PC que ce dernier est plus fort que lui.

    Citation Envoyé par sekaijin Voir le message
    Je comprends que l'arrivée de Nashorn est une erreur monumentale de tous les ingénieurs de la planète qui oeuvre à faire évoluer Java.
    Ah bon, ajouter une fonctionnalité est synonyme de souffrance de faiblesse. Dans le monde actuelle il y a de l'HTML5 et du JavaScrip côté serveur et dans le monde Java on développe des applications qui ont besoin de manipuler les stands du web, javascript en particulier, comme l'IDE netbeans bien fait pour les appli web en Html5, pour bureau et mobile.
    Alors pour faciliter le débogage et les testes il faut quelque chose de standard pour faciliter sont intégration sur la machine virtuelle, Nashorn n'est pas le premier.

    Et tout ce que je peux craindre en sécurité, il n y a pas, car JavaScrpt est interprété par la JVM et non compilé en baytecode. Nashorn facilite l'intégration d’interprétation des codes html et javascript embarqués sur des webview en JavaFX et autre, c'est une fonctionnalité pour un besoin pas une évolution dans le sens que le langage souffre d'une limite.

    Citation Envoyé par sekaijin Voir le message
    Je comprends que les chercheurs en informatiques qui pondent et utilisent des langages dynamiques se sont tous fourvoyés depuis des décennies.
    On dirait que tu lises programmation dynamique en recherche scientifique et tu planques dessus les langages dynamique, ça n'a rien n'avoir. Les algorithme dynamiques n'ont rien n'avoir avec les langages, on utilise des structure de données dynamiques(liste,arbres,graphes) et on a même pas besoin vraiment de programmation orienté objet basé sur des classes. Oublions même le prototypage.

    J'ai bien compris que EcmaScript est un langage pourri bon à jeter qu'il ne faut surtout pas l'utiliser pour ce qu'il sait faire.
    C'est ce que tu penses mais ça ne sort pas de ma bouche, j'étais toujours d'accord qu'il offre une souplesse et je l'utilise. Aujourd'hui même j'étais entrain de coder avec.
    Je vais m'empresser de dire à tous les ingénieurs système qu'il faut qu'ils arrêtent d'utiliser les Shell script et utilisent au plus vite leur compilateur C/C++ pour leur besoin.
    Je n'ai nulle part dis qu'il faut laisser les langages de script ou dynamiques. On était entrain de parler du dynamisme sur les objets et ce qu'il présente comme faiblesse et tu veux faire que la gloire de javascript est basé sur ça et tu me ramènes Shell qui n'est même pas objet et la POO avec PowerShell de Windows sur .NET est basé sur les classes.

    Je me refuse à dire que les langages à base de classe statiques sont de mauvais langages.
    Je n'ai pas aussi dis que JavaScript est le mauvais des langages, il a des faiblesses, reconnaissons les c'est tout. C'est qui permettra d'évoluer. Mon enfant qui a un caractère que je n'aime pas, je ne ne jette pas et je ne l'enterre pas, je l'aime c'est mon enfant, mais je dois lui faire améliorer le comportement.

    Si tu lances des messages à troll comme quoi le prototypage montre la force de javascript devant ses occurrents, ça ne passera pas tu auras toujours des obstacles. Car si tu veux ouvrir la porte aux comparaisons alors en voulant être honnêtes avec nous même et présenter les choses dans leur réalité, il n y a même pas de comparaison, tu risques de tomer dans un gouffre car on te rappellera des choses très moches en javascript.

    Quand on parle de là où on va avec JavaScript restons dans le carde de JavaScript pensons sur comment améliorer les choses quels sont les nouveautés, quels sont les projets futures pour améliorer le langage. Ne cherche pas toujours à vouloir faire des comparaison et toute personne qui lit tes messages voit comme si tu pointe le doigt sur les autres et on peut ponter sérieusement sur javascript.

    Et après tu dis moi j'utilise les langages à typages static, ils sont aussi fort mas.., est ce que tu as besoin de parler de ce que à ton avis est une faiblesse quand on parle de javascrpt et essayer de mettre les mettre tours deux dans une balance pour poser des réserves après?

    Et parfois tu fais un double discours quand tu as donné la comparaison et je t'ai répondu tu as trouvé un issue dans la réponse, regarde bien ce que tu as dis
    Avec un typage statique il faut créer de nouveaux objets à chaque fois que la personne évolue pour passer de Bébé à Enfant Ado Adulte etc.. mais la vie n'est pas ainsi. On reste toujours la même personne. Une nouvelle personne n'est pas créée quand on quitte l'enfance pour devenir un ado
    .....
    JS est un langage qui permet de faire vivre ces objets en les faisant évoluer, chose que ne permet pas les langages avec un typage contraint et statique.
    Qui t'a dis qu'il faut créer de nouveaux objets", toute personne qui lit ton message comprend que ce que tu dis, il faut c'est il faut, c'est une limite et une faiblesse pour les langages à typage static de même en lisant "chose que ne permet pas", pourquoi avancer des propos ainsi, les attributs dans une map ou liste n'appartiennent pas à l'objet, ou tu ne veux pas différencier entre les attributs que je connais déjà et ce qui évolue dynamiquement.
    Que ce qui ne permet pas de faire ce qu'on veut. Et puis quand je t'ai montré l'ensemble des techniques existantes tu dis que tu n'a pas dis qu'il y a de solution, ah bon au moins souligne le et puis tu ajoutes dans ton message:
    je dis que le typage dynamique, et la possibilité de changer dynamiquement un objet n'existe pas avec les typage statique et que donc il faut pour cela trouver des moyens pour représenter un objet évolutif ce qui en javascript s'écrit naturellement.
    Ah bon tu as dis ça avant?? Tu l'a dis nulle part dans ton message, tu lancé le troll et tu as laissé les gens croire que les langages à typage static ont des faiblesses, tu as bien bien dis qu'il faut créer" donc obligation et contrainte=> faiblesse. Ce qui représente une affirmation purement fausse et trollesque.

    Moi quand je dis qu'on ne peut pas faire ça avec javascript c'est qu'on ne peut pas et on ne pourra jamais, pas de technique pour remédier à ça, à moins qu'on fait évoluer le langage, ainsi mon affirmation n'est pas : "on ne peut pas" c'est grave!!! N'amènes pas des exemples qui n'ont pas de place ici. Et déjà on est pas là pour comparer des concepts on parle de JavaScript.
    Car il est clair, que la réponse à la question
    Où va-t-on avec JavaScript ?
    est
    On doit le faire disparaître au plus vite.
    Comment oses tu dire une chose pareil, c'est ça ta conclusion? Tu es loins de mes intentions et mes objectifs à l'égard de JavaScript, on ne tue pas les étudiants qui ne bossent pas bien, on essayer de les faire améliorer.
    Moi j'accepte les faiblesses de javascript mais je l'utilise et je l'utiliserais encore, il a encore a de beau jour devant lui. Je coderais mes applis Html5 avec, et même Modern UI, il est hors de question de faire du C#/XAML, JavaScript répond au besoin et me permet des gains en productivité.

    Je suis toujours contre le fait d'utiliser des outils comme GWT ou JSF pour créer des appli web en java qui sont compilé en javascript et pourtant je suis aussi un développeur java. Je les jamais utilisé et je ne le utiliserais jamais sauf si on me force de le faire. Dans un navigateur il faut du code simple et plus léger que de bouffer la mémoire pour rien, JavaScript est fait pour ça, personne ne dit le contraire. Mais ne mélangeons pas les choses car ça ne se mélange pas.

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

    Informations professionnelles :
    Activité : Urbaniste
    Secteur : Santé

    Informations forums :
    Inscription : Juillet 2004
    Messages : 4 205
    Points : 9 127
    Points
    9 127
    Par défaut
    J'avais dit que je n'interviendrais pas
    mais
    Je constate,
    j’espère, que pour une fois on lira ce que je dis et non ce qu'on veut me faire dire.
    tous mes messages ou presque commencent par
    je n'ai pas dit que
    Tu prends comme exemple le fait qu'on peut ajouter une clef à une map avec le fait d'ajouter un membre à un objet. Je dis que dans les domaines ou on en a besoin l'ajout de membre est une force et l'absence une faiblesse une map ne remplace pas un membre même si on peut trouver des moyens pour simuler un nouveau membre.
    Et dans les cas où on n'en a pas besoin, cette caractéristique devient une faiblesse, car elle implique une perte de contrôle de la sécurité de l'objet.

    Je me fais quasiment incendier, car je dis que lorsque cela correspond au besoin cette caractéristique est une force. Et je dis que c'est vrai pour toutes les caractéristiques de tous les langages. Lorsqu'elles sont en adéquation avec le besoin, c'est une force. Lorsqu'elles sont en opposition avec le besoin il faut trouver un moyen de contourner ces faiblesses.
    Les classes statiques sont une force pour représenter des objets dont la morphologie n'évolue pas. Et une contrainte pour des objets dont la morphologie évolue, car dans ce cas il faut trouver un palliatif.
    Les Objets dynamiques sont une force pour représenter des objets dont la morphologie évolue, et une faiblesse pour représenter des objets dont la morphologie n'évolue pas. Cars dans ce cas il faut trouver un palliatif pour garantir qu'ils n'évolueront pas.

    À chaque fois que j'ai argumenté sur ce point en tentant de donner des exemples je me suis pris une ruée de brancard me faisant dire que les classes c'est de la merde et mes messages comportent quasiment tous
    je n'ai pas dit que
    je conclus de toutes ces attaques que dire qu'il y a des cas ou c'est un gros avantage est interdit. Que si j'affirme qu'il y a des besoins pour lesquels c'est une réponse efficace c'est obligatoirement affirmer que tout le reste c'est de la merde*! Car à chaque fois que j'ai dit que cette caractéristique du langage est une force lorsque cela correspond au besoin on me prête le propos suivant, les classes statiques ce n'est pas bien.

    Un bébé n'a pas la méthode marcher, mais lorsqu'il devient enfant il la possède, il n'a pas la méthode parler et en devenant enfant il la possède. JS permet de modéliser cela en ajoutant les méthodes au fil du temps Java non. Java ne le pouvant pas il faudra au développeur trouver un moyen de le simuler. Cela ne signifie pas que c'est impossible, cela signifie que le langage ne le propose pas. C’est tout.

    Ah bon tu as dit ça avant?? Tu l'as dit nulle part dans ton message, tu lancé le troll et tu as laissé les gens croire que les langages à typage statique ont des faiblesses, tu as bien bien dit qu'il faut créer" donc obligation et contrainte=> faiblesse. Ce qui représente une affirmation purement fausse et trollesque.
    Trouve-moi en Java un moyen d'avoir un objet qui sans être réinstancié (crée un nouvel objet) ne possède pas une méthode A à un instant T et la possède à l'instant T + 1. dans un langage à base de classes statiques c'est tout bonnement impossible. Soit ton objet possède la méthode est tu bricoles un moyen quelconque pour que la méthode ne puise pas être invoqué avant l'instant T, mais puisse l'être après. Soit ta classe, ne possède pas la méthode et il faut instancier un nouvel objet. Tu le dis toi même il y a des moyens de faire avec du code ce que le langage JS propose naturellement. Ce qui est exactement ce que je dis.

    le propos de départ était Où va-ton avec JS
    la réponse de certains était Abandon du prototype au profit de classe statique
    Je dis uniquement que faire ça c'est tuer JS, car c'est la caractéristique principale du langage.
    Faire ça c'est remplacer JS par un langage type Java.

    Si, penser que pour certains besoins avoir un langage qui permet de faire évoluer ses objets dynamiquement est une horreur insupportable. Parce qu'on peut faire quelque chose de semblable avec plus de code dans un langage statique.

    Je conclus que c'est aussi vrai pour toutes les autres caractéristiques des autres langages.
    donc le shell qui est interprété est une erreur vu qu'on peut faire la même chose en C/C++
    etc.

    Je ne fais là qu'appliquer ce qu'on me reproche de faire avec les langages à base de classe statiques et que je me refuse à faire, sur d'autre caractéristique d'autres langages.



    Lorsque cela correspond au besoin, cette caractéristique est une force.

    Lorsque le typage statique ne correspond pas au besoin, c'est une faiblesse.

    Et vice versa.
    Je n'ai rien dit de plus.

  17. #257
    Expert confirmé
    Avatar de le_chomeur
    Profil pro
    Développeur informatique
    Inscrit en
    Février 2006
    Messages
    3 653
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Février 2006
    Messages : 3 653
    Points : 4 835
    Points
    4 835
    Par défaut
    Salut Sekaijin !

    j'ai lu bon nombre de tes réponses sur le sujet "ou va t-on avec javascript" ( dont j'étais l'auteur ^^ )

    et je suis bien souvent d'accord avec toi, de nombreuse personnes ont posté non pas pour indiquer ou va t-on, mais ou ils aimeraient aller et il aurait fallut recentrer le débat sur l'utilisation actuel du javascript plutôt que sur les orientations et évolutions du langage lui même !

    NodeJS aillant explosé ces derniers temps, l'emac 6 arrivant j'espère dans quelques temps également nous allons avoir un langage de programmation qui paliera avec certains de ses défauts ( module, classe, variable ( constantes ... )

    Mais n'oublions pas la base de ce langage ! réaliser des interactions intelligentes entre l'interface et l'utilisateur !

    Beaucoup d'utilisateurs ( et encore plus depuis mon premier post :'( ) passent par des librairies/ framework sans même comprendre les fondamentaux de ce langage, d'ou les dérives dans ce post/débat ....

    Voila mon humble avis
    est ton ami fait gagner du temps à ceux qui aident , donc un message avec la balise résolu laisse plus de temps pour résoudre d'autres problèmes

    Premier ministre du CCMPTP (Comité Contre le Mot "Problème" dans les Titres de Posts )

  18. #258
    Membre chevronné
    Avatar de la.lune
    Homme Profil pro
    Directeur Technique
    Inscrit en
    Décembre 2010
    Messages
    545
    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 : 545
    Points : 2 084
    Points
    2 084
    Par défaut
    tout le monde!

    Avant d'entrer au fond de mon message que j'ai décomposé en deux pour ne pas fatiguer en lecture , je saisis d'abord l'occasion pour présenter mes excuses à toi sekaijin, si j'étais un peu disons ferme envers toi dans mon dernier message, de même si je n'ai pas interprété à 100% tel que dit. Mais d'une part il faut accepter le critique, on analyse des faits et des propos, possible que je fasse une erreur, mais moi je me base en générale sur plusieurs interventions à toi dans ce forum, je connais parfaitement ton discours.

    Je rappel de même que ce qui m'anime aussi c'est dès que tu entends parler du typage static pour le web en générale ou javascript en particulier, tu a tendance à pencher sur le fait de dire que ce n'est pas toujours beau avec si on veut l'utiliser dans le contexte du web, avec plein de messages comme quoi on ne peut pas faire ça là-bas et on ne peut pas faire ceci, c'est faible, c'est limité...

    Pourtant je ne prétend pas que tu dis qu'il faut jeter ses langages à typage static, ou fortement typé, mais au lieu d'être plutôt optimiste et voir l’intérêt de l'ajoute du typage le typage static et la POO à base de classe optionnellement à javascript à côté du typage dynamique et le prototypage, ton discours est ferme:

    "Non au typage static en JavaScript, dans le contexte de javascript on peut TOUT faire avec, pas de faiblesse; Que ce qu'on ne peut pas faire avec javascript dans sont contexte?" Et là tous les messages plus ou moins à caractère trollesque commencent, c'est ça en fait ce qui me pousse à agir ainsi; Alors e m'excuse encore

    Pour répondre à ton message précédant et le défi que tu as posé, il me fallait un peu de temps pour tout rédiger et détailler un certains nombre de chose sur le vrai comportement de JavaScript, et coder quelques exemples, pour bien cadrer le débat.
    A suivre....

  19. #259
    Membre extrêmement actif
    Profil pro
    Inscrit en
    Décembre 2003
    Messages
    1 616
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2003
    Messages : 1 616
    Points : 3 965
    Points
    3 965
    Par défaut
    sentiment personnel, tant pis...

    t'es lourd la.lune ... arrête de faire du procès d'intention, et si tu veux faire je ne sais quelle démonstration, essaie peut être de le faire dans un autre topic, non ?

    enfin je sais pas, mais le titre du topic, c'est "Où va-t-on avec JavaScript", pas comment utiliser le pattern "décorateur" en java, ou je ne sais quelle autre démo...
    Émotion
    Infantilisation
    Culpabilisation

    Christophe Alévèque - 18 Mars 2021

  20. #260
    Membre chevronné
    Avatar de la.lune
    Homme Profil pro
    Directeur Technique
    Inscrit en
    Décembre 2010
    Messages
    545
    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 : 545
    Points : 2 084
    Points
    2 084
    Par défaut
    Même si la question posée concerne le typage static mais ça permet d'exposer les bases et comment ça se passe de javascript et ma conclusion va dans le sens où va ton avec javascript et pourquoi nous sommes encore là. Quel l’intérêt des autres approches. Ainsi, la problématique posée sur l'ajout dynamique de méthode concerne le typage static à base classe en comparaison avec le prototypage.

    sans être réinstancié (crée un nouvel objet) ne possède pas une méthode A à un instant T et la possède à l'instant T + 1. dans un langage à base de classes statiques c'est tout bonnement impossible
    J'aurais aimé à ce qu'on évite les message genre "c'est c'est impossible", comment impossible? Et si on veut l'équivalemment d'une chose exactement entre le typage static et dynamique, disons le et il ne faut qu'on se fie aux apparences.

    Je vais présenter un concept mais avant qu'on me dit comme quoi en javascript tout est objet, car je l'ai lu pas mal de fois sur ce forum comme quoi en javascript tout est objet, alors je le dis avec les preuves à l'appuie que ce n'est pas vrai, en javascript tout n'est pas objet, seuls les membres de type Object le sont.

    Je ne dis pas ça parce qu'on utilise pas de constructeur explicitement lorsqu'on manipule des littéraux, mais c'est parce qu'ils ne sont point c'est tout, à moins qu'on utilise des littéraux en créant des objet {..},[...]. La valeur primitive est stocké telle quelle est, il ne fait référence à aucune propriété comme un objet. Pas d’instanciation!! Prenons le soin de bien lire la norme et évitons le jugement sur les comportement superficiels

    Si en dehors du site officiel de ECMA, vous pouvez entendre dans certains site dire que: "tout est objet en javascript", il faut faire attention à ce qu'on veut dire!! Je prend l'exemple de w3schools.com, il faut bien lire ce qui est écris après: "tout (sauf..) peut être traité comme des objets" et non pas "tout est toujours traité en objet"

    Ce qui se passe c'est qu'en cas de besoin, tout passe simplement par une conversion implicite vers un membre de type Object, en appelant le constructeur correspondant(wrapper) lorsqu'on manipule des littéraux représentant des valeurs primitives ou des variables contenant des valeurs primitives et qu'on veut appliquer des comportements comme sur des objets, c'est ça ce que dit la norme. Une opération abstraite ToObject tel que définit la norme est réalisé.

    Il est nulle part dis dans la norme ECMAScript comme quoi les valeurs primitives sont des objets ou qu'il héritent d'une chaîne de prototype quelconque, ce n'est pas vrai. La norme[1] dit:
    4.3.2 primitive value
    member of one of the types Undefined, Null, Boolean, Number, or String as defined in Clause 8
    NOTE: A primitive value is a datum that is represented directly at the lowest level of the language implementation.
    Une valeur primitive est une donnée qui est représentée directement au niveau le plus bas de la mise en œuvre de la langue.
    Par contre un objet est défini comme une collection de propriétés (là je vais en venir sur la 2e partie), comme c'est dit :
    8.6 The Object Type
    An Object is a collection of properties. Each property is either a named data property, a named accessor property, or an internal property...
    La norme définit toujours en séparant trois choses pour les données, sauf pour Undefined et Null, définit en deux, et Object en un, par exemple pour un number on a : Number Value, Number Type et Nymber Object, le Number Type c'est pour les valeur primitives de type Number. Il ne faut pas mélanger les choses.

    Ainsi, si je peux faire 20..toString()//"20" ou 20["toString"]()//"20" c'est juste de la conversion en appelant le constructeur de Number et puis la méthode toString de l'objet Number, ce n'est pas que 20 fût stocké en instanciant un objet . Je peux faire undefined+""// "undefined", mais essayez de faire undefined..toString() ça ne va pas marcher car il n'existe pas de constructeur de type Object pour undefined, et le premier cas il a concaténé en faisant new String(undefined).toString()Pour voir que c'est réellement de la conversion implicite
    Si on fait d'abord
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    3 instanceof Number;//false
    3 instanceof Object;//false
    var a=3; 
    a instanceof Number;//false
    a instanceof Object;//false
    , donc pas d'appel du constructeur, Mais si je fais:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    var b=new 3..constructor();// b=Number{}
     b instanceof Number;//true
     b instanceof Object;//true
    3..__proto__.meth =function(){ console.log("sss")};
    a=new Number();//a==Number{meth:function}
    On voir que maintenant il fait appel au constructeur Number, et pour les deux derniers lignes vous voyez que c'est le prototype de l'objet Number qui est modifié en ajoutant quelque chose au type.

    A présent je vais pourvoir parler sur la problématique posé. Premièrement, il ne faut pas ignorer que ECMAScript définit une méthode tout simplement comme une valeur d'une propriété de l'objet, comme c'est défini déjà: un objet est une collection de propriétés, on map des nom avec des valeurs.

    En plus de ça, sans instanciation d'un objet de type Function c'est impossible en javascript de définir une function(méthode) qui est par définition dans le monde de la programmation un ensemble de traitements séquentielles sans état,(des instructions groupés en sous programme comme les procédures), en javascript cette instance est un vrai objet avec plein de propriétés et méthodes propres(en fait des objets de type Function propres).

    Dans les langages à typage static l'objet n'est pas crée en portant avec elle le corps de la méthode mais il fait juste référence à la méthode, il ne sera appelé que si la méthode est invoqué et enfin de méthode tout est détruit.

    Par suit, l'appel d'une méthode en js ne revient pas à l'appel d'une méthode de l'objet en soit mais pas à l'appel implicite d'une autre méthode de l'objet fourni en valeur de cette propriété de l'objet. La norme parle même "d'implémentation" de la méthode interne(propriété interne) Call pour les fonction quand on les définit.

    Relisions ensemble la norme, d'abord c'est quoi une fonction[1]
    4.3.24 function
    member of the Object type that is an instance of the standard built-in Function constructor and that may be invoked as a subroutine
    NOTE In addition to its named properties, a function contains executable code and state that determine how it behaves when invoked. A function’s code may or may not be written in ECMAScript.
    Une fonction est un membre du type Object, (ce n'est même pas une valeur primitive, ni un ensemble de traitement séquentiel sans état comme en java), c'est une instance du constructeur Function intégré, il peut être invoqué comme des sous programmes(pas des sous programmes proprement mais comme..)....une fonction contient du code exécutable et un état ​qui détermine son comportement une fois invoqué.
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    A.m=function(){console.log("methode");}//function (){console.log("methode");}
    A.m instanceof Object;//true
    A.m instanceof Function;//true
    Ainsi, les instructions suivantes sont syntaxiquement différentes mais fonctionnellement les même, même résultat, même comportement:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    obt.A=function(b){console.log('valeur=',this.a+b)};
    obt.A=new Function("b","console.log('valeur=',this.a+b)");
    Et c'est quoi une méthode[1]:
    4.3.27 method
    function that is the value of a property
    NOTE When a function is called as a method of an object, the object is passed to the function as its this value.
    Une fonction(donc objet) qui est une valeur d'une propriété...

    Le seul intérêt syntaxiquement c'est que le fait de l'invoquer via un objet il passe l'objet comme la valeur this de la fonction, mais cela ne veut pas dire qu'il est lié, on peut corrompre ça en faisant un appel explicite ce qui rend cette technique juste une syntaxique simplifié.

    Quand je fais :obj.m(3), il fait tout simplement obj.m.call(obj,3);, et je peux le faire aussi et vu que la méthode est un objet à part, je peux facilement appeler la méthode indépendamment du contenu "this" de l'objet, ce qui fait la porté de "this" n'est en rien devant l'objet Function passé en valeur, qui n'est pas une méthode vraiment de l'objet. exemple de code:
    Code javascript : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    var obj={};//Object {}
    obj.m=function (b){ console.log(this.a+b)}
    obj.a=3;
    obj.m(3);//6 
    obj.m.call(obj,3);//6 
    obj.m.call({a:20},3);//23 
    console.log(obj.a===3);//true
    Il peut facilement ignoré le contenu de l'objet. Par ce que ça ne lui appartient pas, mais on passe l'objet à l'objet Fonction lors de l'invocation.
    Une méthode d'un objet en javascript est juste un ensemble de comportement, on les embarque dans un objet et on passe ce dernier à une propriété de l'objet. En plaçant des parenthèses devant la propriété en fournissant des paramètres, il fait son invocation.

    Je peux créer une autre manière d'invocation de méthode d'objet et faire aussi passer this à la fonction qui fait l'appel, c'est très simple, même si je ne connais pas les paramètres de la méthode qui sera invoqué.
    Code javascript : 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
    26
    27
    28
    Object.prototype.appel=function(nom){ 
       var f=this[nom];
        if(!(f instanceof Function)) throw "Erreur de type: ce n'est pas une méthode";
        //Je dois enlever le premier argument qui est le nom, pour passer les vrai paramètres
        //l'objet "agruments" ne possède pas la méthode slice car il n'est pas de type Array
        for(var i=0;i<arguments.length-1;i++)arguments[i]=arguments[i+1];
     
        return f.apply(this,arguments);
    };
    //==============
    //POUR TESTER
    //==============
     
    var a=new Object();
    a.val=5;
    a.ajoute=function (a){
        return this.val=this.val+a;
    };
    a.affiche=function(){console.log(this.val);};
    console.log(a.ajoute(10));//10
    console.log(a.appel("ajoute",10));//20
    a.affiche();//20
    a["affiche"]();//20
    a.appel("affiche");//20
    a.somme=function f(a,b,c){
        return a+b+c;
    };
    console.log(a.appel("somme",3,3,3));//9
    Ce n'est pas que dans certains langages à typage static je ne peux pas surcharger l'opérateur des parenthèses que cela veut dire qu'on ne peut pas faire exactement ce qui se passe en javascript, en C++ je peux surcharger les parenthèses et les crochets contrairement à java, en C# je peux aussi surcharger les parenthèses, en C++ je peux définir ce que je veux et faire map["methode"](params) pour invoquer une méthode.

    En javascript on a juste une manière simplifié de l'appel, il appel un objet implicitement, comme on a pas de classe. Mais j'ai une manière plus propre et plus jolie a faire avec la POO à base de classe, si l'objectif ce n'est pas de détruire l'instance créer, on ajoute des méthodes et des attributs à la classe, sans détruire l'objet.

    Les décorateurs n'héritent pas d'objet étendu comme avec l'héritage classique, mais il le porte par composition, du coup il n'est jamais détruit, il faut aussi différencier entre la référence vers l'objet et un objet. Avec le pattern Décorateur j'ai la même référence qui pointe sur un objet qui décore un autre et chaque fois je lui affecte un nouveau objet décorant l'autre sans que l'autre soit détruit(voir plus de détaille la force du pattern Décorateur Annexe A )

    Mais voyons de même que le fait qu'on ajoute des événements à nos composants graphiques qui est le but ultime de javascript(crées pour manipuler des interfaces graphique) est au yeux de ECMAScript de simples méthodes aux objets.

    ECMAScript ne définit pas d’événement dans la norme, les événements est une manipulation du langage par l'API W3C, quand je clique sur un bouton bt1, c'est juste un appel du corps de la méthode stocké dans la propriété, en faisant bt1.onclick() implicitement bt1.onclick.call(), rien ne m'empêche de déclencher le comportement que fera un bouton manuellement dans une méthode, en faisant la même chose bt1.onclick(), j'appel la méthode ajouté à l'objet, c'est ça le but de javascript.

    Pour s'approcher du but, prenons l'exemple de Nashorn , actuellement au lieu d'être borné en java pour les applis natives je peux coder mes applications JavaFX en javascript, alors en JavaFX par exemple pour ajouter une méthode à un bouton je fais la même chose, j'ajoute un objet Fonction à l'objet
    Code javascript : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    var button = new Button();
    button.text = "Dire 'Bonjour !'";
    button.onAction = function() {print("Bonjour tout le monde!");//print sur le jdk est égale à console.log 
    }
    Là je fais un set, affectation d'un objet à une propriété interne. field.setValue("test2") revient à faire field.value="test2"Et en Java et les autre lagunages à typage static? Comment je peux ajouter cette même méthode sur un bouton après avoir instancié un objet de type Button, je fais tout simplement:
    Code Java : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    Button btn=new Button(); 
    btn.setText("Dire 'Bonjour !'");
    btn.setOnAction(new EventHandler<ActionEvent>() { 
    public void handle(ActionEvent event) {
    System.out.println("Bonjour tout le monde");}
    });
    Je passe par une classe anonyme comme en javascript j'utilise un fonction anonyme, qui est un Objet que j'instancie, je peux aussi donné une classe non anonyme comme en javascript je peux donner une fonction non anonyme, afin de pouvoir a partager entre plusieurs objets.

    Ce qu'il faut éviter aussi c'est de dire que les langages à typage static ne sont pas fait pour ça, donc toutes les interfaces graphiques codés en Swing,AWT,SWT,JavaFX ne sont pas faire pour ça, tous ces années ils ont vécus et qu'ils continuent aussi, ils étaient entrain de bidouiller? Mais c'est eux même qui ont crée javascript alors comment ils se sont trompés et continuent à utiliser.

    Alors que cette syntaxe, non seulement non IDE génèrent automatiquement, mais on a voulu faire quelque chose qui sera bien compilé et bien structuré, et plus de gains en performance. Que la syntaxe en java enchante les codeurs ou pas, on fait la même chose qu'en javascript. EventHandler est aussi une interface donc classe purement abstraite, dont on doit définit la méthode handle.

    Mais avec les expression lamda existant en java et C++,C# on a facilité juste la syntaxe car le compilateur est plus intelligent, il connaît les interfaces à chercher, et il n'instancie pas un objet comme les class anonymes ou les fonction annymes, mais il fait appel à l'expression au moment de l’exécution, pas besoin d'instancier un objet et la placer en mémoire.
    Code Java : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    btn.setOnAction((ActionEvent event)-> {
    System.out.println("Bonjour tout le monde");}
    );
    Alors de la même manière que je crée un objet en javascript et je crée un objet en java, pour définir un comportement dynamiquement.
    Citation Envoyé par sekaijin Voir le message
    Tu prends comme exemple le fait qu'on peut ajouter une clef à une map avec le fait d'ajouter un membre à un objet. Je dis que dans les domaines ou on en a besoin l'ajout de membre est une force et l'absence une faiblesse une map ne remplace pas un membre même si on peut trouver des moyens pour simuler un nouveau membre.
    Il ne faut pas ignorer que la norme ECMAScript aussi définit l'accès aux propriétés et la récupération comme comme la manipulation d'un map. Par définition, les ajouts et récupération sont définis par les opération GetValue (V) et PutValue (V, W)(voir section 8.7.1 et 8.7.1)exactement comme une map, chaque objet possède en interne la propriété put et get, le reste sont des sucres syntaxiques.

    Un Objet en javascript est une collection de propriétés ce n'est pas le cas dans les autres langages à base de classe. Essayons de comprendre, il n y a pas de la magie dans la programmation ajouter dynamiquement c'est une structure de données dynamique point barre qu'on peut faire même avec le langage C

    Je me pose la question membre en javascript est-il synonyme de a.membre mais quand je fais a["membre1"], membre1 n'est pas membre, n'est ce pas? et quand je fais a["membre"]["membre2"], membre2 n'appartient pas à l'objet a, mais seulement à membre, n'est ce pas? il y a seulement des objets simples, les objets complexes ça n'existe pas? et pourtant un objet en javascript est un objet complexe et simple dans l’apparence.

    Ce qui se passe, c'est comme en C#6 où ils ont étendu les objets indexés(map et autres) avant on pourrait faire seulement obj["cle"]="valeur" mais maintenant on va pouvoir faire obj.cle, et dans tous les deux cas c'est obj.put("cle","valeu") et obj.get("cle"). Rien ne dit que le langage souffrait d'une faiblesse avant cette sucre syntaxique?

    S'il y a simulation c'est bien la notation de pointé en javascript car il cache de que définit la norme et ce qui se passe vraiment, alors que ce n'est même pas le fond du langage qui code le moteur mais la simple structure interne d'un objet javascript. Les attributs et propriétés crée à l’interne de l'objet.

    Avec Nashorn je gère un objet map en javascript comme un simple objet javascript si j'instancie une map, mais avec Nashorn j'ai des outils de plus, la méthode put() et get() rendu à la portée des utilisateurs,
    Code javascript : 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
    var objet = new java.util.HashMap();
    // accès avec les méthodes get et put
    objet.put('js', 'nashorn');
    print(objet.get('js'));//=>nashorn
    // accès par clé et la syntaxe propre des proprietés
    print(objet['js']);//=>nashorn
    print(objet.js);//=>nashorn
    objet['language'] = 'java';
    print(objet.get("language"));//=>java
    print(objet.language);//=>java
    print(objet['language']);//=>java
    objet.answer = 42
    print(objet.get("answer"))//=>42
    objet.put("affiche", function(){
    print("Bonjour");
    });
    objet.affiche();//=>Bonjour
    objet.affiche2= function(nom){
    print("Salut "+nom +" !");
    };
    objet.get("affiche2")("sekaijin");
    //=>Salut sekaijin !
    objet.get("affiche2").call(objet,"sekaijin");
    //=>Salut sekaijin !
    Ainsi, en plus que c'est du simple mappage, mais aucune syntaxe n'est synonyme de faiblesse ou de force devant l'autre.

    Pour cela, afin de réaliser un comportement purement dynamique en java en attribut et méthode, en quelque minute j'ai défini moi même une classe représentant un objet dynamic selon mon besoin, que je peux utiliser toujours et elle est générique et ma map est privé, seul moi a accès, et pas de possibilité à l'utilisateur d'appeler la méthode remove pour tuer mon objet

    Pour ajouter une méthode j'ai crée une interface Méthode pour n'importe quel méthode, elle a besoin connaitre la type "Type" de retour de la méthode. Ce sont des choses existantes dans l'API standard de java mais je préfère créer moi même ce que je veux.
    Code Java : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    public interface Methode<Type> { 
       public Type call(DynObject This, Object... args);
    }
    Voici ma classe, l'utilisateur à droit à _g() pour faire un get de propriété et un _s() pour un set d'un valeur et une une méthode appel(), et un message d'erreur si ce n'est pas une fonction
    Code Java : 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
    public class DynObject { 
       private final HashMap map=new HashMap();
      //je définit la méthode get _génriquement
      public <U> U _g(String s){
          return (U)map.get(s);     
      }
        //je définit la méthode _s
      public void _s(String s, Object o){
         this.map.put(s, o);
      } 
      public <Type> Type  appel(String name_methode, Object...args){
          //Pour ne pas rompre le programme en cas d'erreur mais ça peut compiler sans le try catch
         try{         
         Methode<Type> methode=this._g(name_methode);
         //La technique d'inference de type permet de savoir le type de retour qu'il est correct
         return methode.call(this, args);
     
         }catch(ClassCastException e){
             System.err.println(name_methode+" n'est pas une méthode");
             return null;
         }
      }
    }//DynObject
    Donc, après je fais ce que je veux dans une méthode principale où n'importe et quand je crée une fonction mon IDE me génère le squelette par défaut de des l'interface Function je lui donne les types c'est tout et puis je code seulement,
    Code Java : 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
    26
    27
    28
    DynObject obj=new DynObject(); 
        obj._s("cool",true);
         obj._s("id",2014);
         obj._s("log","La.lune");
         obj._s("adress",new String[4]);
         obj._s("sous_membre",new DynObject());
         obj._s("affiche", (Methode<Boolean>) (DynObject This, Object... args1) -> {
                             System.out.println("ID :"+This._g("id")+", "
                                              + "Tu es cool :"+This._g("cool")+", "
                                              + "Login :"+This._g("log"));
                         return true;
            });   
         obj._s("somme", (Methode<Integer>) (DynObject This, Object... argv) -> {
                return (int) argv[0] + (int) argv[1];
            });
               String longin=obj._g("log");
               boolean cool=obj._g("cool");
               int id= obj._g("id");
               obj.appel("affiche");//<=>obj.obj["affiche"]()
               //ou bien
               obj.<Methode>_g("affiche").call(obj); 
               int somme=obj.appel("somme",3,7);//<=>obj.obj["somme"](3,7)<=>obj.obj["somme"](3,7)
     
               System.out.println("valeur="+somme);
               System.out.println("Deuxième affichage");
               System.out.println("ID :"+id+", "
                                 +" Tu es cool :"+cool+", "
                                 +" Login :"+longin);
    Affichage:
    ID :2014, Tu es cool :true, Login :La.lune
    ID :2014, Tu es cool :true, Login :La.lune
    valeur=10
    Deuxième affichage
    ID :2014, Tu es cool :true, Login :La.lune
    Que ce qui se passe en JavaScript ne se passe pas en Java, fonctionnellement j'ai la même chose seulement les syntaxes différent. Ici j'ai mis le try catch dans appel pour ne pas que le programme s’arrête mais en cas de fourniture d'un objet autre qu'une méthode, mais ça peut compiler facilement.

    Citation Envoyé par sekaijin Voir le message
    Un bébé n'a pas la méthode marcher, mais lorsqu'il devient enfant il la possède, il n'a pas la méthode parler et en devenant enfant il la possède. JS permet de modéliser cela en ajoutant les méthodes au fil du temps Java non
    Ah bon! les interfaces graphiques en java viennent tous avec les actions a réaliser déjà faites?
    Là je donne un à ceci
    Citation Envoyé par le_chomeur Voir le message
    Mais n'oublions pas la base de ce langage ! réaliser des interactions intelligentes entre l'interface et l'utilisateur !
    Ce que j'aurais aimé souligner c'est qu'il ne faut pas détourner javascript de son but ultime, et avec cet exemple du bébé, je ne vois pas sa place ici. Un bébé oui, il n'est pas né avec la fonction marcher ou parler. Mais il ne faut pas oublier que c'est impossible à un bébé d'avoir dans le future la fonction imprimer ou démarrer, ou voler comme un oiseaux. Toutes les fonctions sont préalablement connus, mais on les actives après.

    Et pour faire marcher le bébé je ne suis pas obliger de faire une opération sur l'enfant pour lui faire marcher. Au cours du temps, j'appel des des méthodes, des getter et des setters pour remplir ses propriétés(connaissance, énergie, fortifier ses muscles) et au court du temps on active les méthodes qui sont susceptibles.

    Ainsi, soit je lui ajoute des valeurs à ses attributs dynamiquement et définir les nouveau comportement à leurs places soit je lui décore avec une nouvelle méthode et fonctionnalité sans le tuer.

    JavaScript n'est pas fait pour venir faire div.onfocus=function(){} car il n'existe pas quelque chose qui s'appel focus sur un div.

    Par suite, il ne faut pas utiliser les concepts de javascript là où ils ne sont pas crées pour. Si je n'ai pas besoin pour un composant graphique déjà crée, le but d'une méthode c'est factoriser un ensemble de tache pour plusieurs objet de même types, et là je passe par la définition via la propriété prototype pour que tous les objets bénéficient, donc comme les classes, même si en javascript je crée un objet.

    Faire sortir la notion de méthode des deux concepts revient à utiliser javascript en dehors de son but, et pondre des méthodes pour chaque objet que seul le codeur connait.

    J'aurais aimé souligner qu'
    un développeur voit la finalité d'une chose et non pas la syntaxe, les syntaxes oui c'est jolie et c'est beau et souple, mais ce n'est pas une finalité en soi. Le faite d'écrire en CoffeeScript somme=(a,b)->a+b; et qu'en javascript je dois écrire function somme(a,b){ return a+b;} ça ne veut pas dire que CoffeeScript est plus fort que Javascript et que ce dernier est faible et il n'est pas fait pour ça. De même que document.getElementByID("id") ne veut pas dire que JQuery est plus fort que l'API standard, il offre juste une souplesse au détriment de la consommation de la mémoire et des performances

    Conclusion

    Le monde n'est pas dans l'erreur s'ils reconnaissent en principe l’intérêt de CoffeScript, TypeScript, Dart, des outils comme GWT,JSF en java et fond de bon programme dans le contexte de JavaScript et ça marche très bien. Même si c'est bien mais ce n'est vraiment la bonne solution. Je serais obligé à migrer vers Dart pour un gros projet, par ce que je n'ai pas le choix.

    Nous ce qu'on veut en JavaScript c'est qu'on ait le choix de faire autre chose que le prototypage sans tuer cette belle notion qui nous sert aussi. La grosse erreur faite pour javascript c'est l'enterrement de la version 4 de ECMAScript et on est passé après à la version 5.

    Le ES4[2] permettrait d'avoir toutes les notions objets à base de classe(interface, package, class,encapsulation, module), et tout ça sa tuer le prototypage. Il est même dit que toute classe posséderait la propriété prototype, ce qui n'existe pas dans les langages à typage static. Qui dit qu'on doit tuer le prototypage?

    Par suite avec les contestations par ici par là comme quoi javascript dévie son chemin, ils ont enterré la norme et voila comment le monde est devenu, pour se rendre compte 3 ou 4 ans ans après qu'ils ont commis une grosse bêtise.

    Ceux là qui n'ont même pas participé à son élaboration, ce sont ceux qui font l'hypocrisie aujourd'hui et viennent pondre TypeScript et Dart. Google n'a fait que copier ES4, il savait ce que le web allait devenir, et au lieu de se rattraper, il a pondu un autre langages alors que le but du web c'est la standardisation des choses et le multi-plateforme le maximum possible, rien qu'avec js on souffre parfois pour le cross browser imaginez si on fait du web comme en natif

    Quand Abobe, Mozilla, Opera et les autres ont crée la spécification où est ce qu'ils étaient? Du côté des contre bien sûr, possible parce qu'ils cachaient déjà leur projet. Comment Google pourra convaincre ces concurrents d'adopter son langage alors que lui même a laissé tomber ES4 proposé par ses concurrents .
    Ou bien ils veulent à tout prit que la valeur de javascript dans le web soit effacé dans l'histoire et que ça revient à leur propre langages . Ainsi, on sera dans certains cas obligé de migrer si les navigateur n’implémente pas ces principe de la POO en javascript.

    Liens de reference
    [1]ECMA Internationale Standard ECMA-262,Edition 5.1,Juin 2011
    [2]Référence de la proposition de ECMAScript 4

    Annexe A
    Exemple d'utilisation du pattern Décorateur;
    Code Java : 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
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    68
    69
    70
    71
    72
    73
    74
    75
    76
    77
    78
    79
    80
    81
    abstract class AbstractPersonne{
        String nom;
        int age;
        //Par défaut on a ça
        abstract void pleurer();
        abstract void dormir();  
    }
    //Un bébé est né une seule fois
    class BB extends AbstractPersonne{
     
     
        public BB(String nom, int age) {
            this.nom=nom;
            this.age=age;
        }
     
    void pleurer(){
        System.out.println(nom+" pleure");}
    void dormir(){
        System.out.println(nom+" dort");}
    }
    abstract class Decorateur extends AbstractPersonne{
    AbstractPersonne decoré;
        public Decorateur(AbstractPersonne decoré) {
            this.decoré = decoré;
        }
    public void pleurer(){
    decoré.pleurer();}
     
    public void dormir(){
       decoré.dormir();}
     
        public AbstractPersonne getDecoré() {
            return decoré;
        }
    }
    class FuncsEnfant extends Decorateur{
     
        public FuncsEnfant(AbstractPersonne personne) {
            super(personne);
        }
        public void parler(){
            System.out.println(this.getDecoré().nom+" parle");
        }
        public void marcher(){
            System.out.println(this.getDecoré().nom+" marche");
        } 
    }
    class FuncsAdo extends Decorateur {
     
        public FuncsAdo(AbstractPersonne personne) {
            super(personne);
        }
        public void raisonner(){
        System.out.println(this.getDecoré().nom+" raisonne");
        }
        //je connais l'ierarchie
        @Override
         public AbstractPersonne getDecoré() {  
             Decorateur décoration=(Decorateur)decoré;
            return décoration.getDecoré();
        }   
    }
     
    public class Application{
     
        public static void main(String... args) {  
            AbstractPersonne personne;
            personne=new BB("Toto", 0);
            personne.pleurer();
            personne.dormir();
            //Je décore mon BB sans le détruire
            personne=new FuncsEnfant(personne);
            ((FuncsEnfant)personne).marcher();
            ((FuncsEnfant)personne).parler();
            personne.pleurer();
            Object décoré=((FuncsEnfant)personne).getDecoré();
            System.out.println("1:"+(décoré instanceof BB));
            personne=new FuncsAdo(personne);
            Object décoré2=((FuncsAdo)personne).getDecoré();
            System.out.println("2:"+(décoré2 instanceof BB));
    La bébé n'est pas tué pour devenir enfant, il est décoré, il reste toujours en mémoire, est qu'on re-instancie l'objet? Voici le résultat du teste
    Toto pleure
    Toto dort
    Toto marche
    Toto parle
    Toto pleure
    1:true
    2:true

Discussions similaires

  1. navigation dans une jsp avec javascript
    Par petitelulu dans le forum Général JavaScript
    Réponses: 3
    Dernier message: 15/11/2004, 19h55
  2. Defilement de la fenetre avec JavaScript
    Par black is beautiful dans le forum Général JavaScript
    Réponses: 2
    Dernier message: 28/09/2004, 11h21
  3. Lien ASP avec javascript
    Par RATIER dans le forum ASP
    Réponses: 3
    Dernier message: 15/07/2004, 09h54
  4. Réponses: 4
    Dernier message: 27/04/2004, 15h45

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