Bon les programmes ne sont pas vraiment équivalents, la version PHP est entièrement impérative tandis que la version Python est plus fonctionnelle avec des générateurs de partout, c'est pas une comparaison très honnête. Mais la différence reste surprenante !
./2858 : bon je ne réponds pas à tout parce que flemme :
flanker (./2858) :Heu... tu sors ça d'où ? Ça ne marche pas dans mon browser et ça n'apparaît pas non plus dans la spécification ? (et pas plus dans celle de Mozilla, que je suis allé voir au cas où)
- ça ressemble quand même beaucoup à une table de hash, avec les méthodes keys(), values()
flanker (./2858) :Si jamais pour toi "utiliser les caractères { et } en commun" est un critère alors d'accord, mais pour moi non ça n'est pas exagéré, je pense réellement que le concept n'a rien en commun (pour des raisons déjà expliquées plus haut donc on tourne un peu en rond)
Donc dire que {} n'a aucun rapport, même de loin, avec une hash table me semble un tantinet exagéré
flanker (./2858) :Bah oui bien sûr, là encore c'est le postulat de départ : le JS a été conçu pour être exécuté dans un environnement isolé. Je ne conteste pas le fait qu'on le pousse trop loin en essayant de l'utiliser comme technologie côté serveur et lui faire faire des choses qui n'ont pas été prévues au moment de sa conception. Je dis simplement que replacé dans son contexte c'est un langage qui beaucoup de choix intéressants.
C'est viable quand on bosse sans aucune lib externe, mais sinon, je trouve ça beaucoup trop dangereux.
flanker (./2858) :Pas du tout non, c'est une méthode d'initialisation. La différence réside, entre autres, dans le fait qu'il s'agit d'une méthode tout à fait classique qui suit l'arbre d'héritage des objets. Ça veut dire que si j'ai une classe AbstractMachin qui expose une méthode def __init__(self, x, y) et que j'en fais hériter un ConcreteMachin qui ne redéfinit rien du tout, alors je peux quand même faire machin = ConcreteMachin(3, 5) et ça appelle ma fonction d'initialisation correctement. C'est utilisé dans pas mal d'endroits de la lib standard pour fournir des classes volontairement incomplètes qu'il faut étendre pour pouvoir s'en servir, mais qui ont quand même besoin d'arguments pour être initialisées. Ça fonctionne, mais je trouve qu'avoir troqué les constructeurs pour cette fonctionnalité est trompeur : si je redéfinis une méthode __init__ moi-même et que j'oublie d'appeler celle de mon parent par exemple (parce que j'ignorais qu'elle existait, ou tout simplement parce que je me suis planté) alors je vais me retrouver avec un code qui s'exécute correctement mais va planter ou faire n'importe quoi à l'exécution.
Qu'est-ce que la méthode __init__ a de magique ? C'est un constructeur comme un autre, non ?
Tiens d'ailleurs, c'est très dommage d'avoir choisi une syntaxe qui fait aussi furieusement penser à celle d'un constructeur pour quelque chose qui n'en est pas un (et visiblement beaucoup de gens font la confusion, toi compris, alors que tu n'es pas vraiment un débutant dans ce langage il me semble). Toi qui râlais parce que les objets de JS utilisent une syntaxe proche de celle des hashmaps dans d'autres langages, ça doit te sembler atroce non ?