Il ne supporte pas l'héritage d'interface et nous vend son duck typing.
Un principe révolutionnaire lorsque tu dois faire de l'intégration de composants, surtout couplé avec son typage dynamique. Lorsque tu assembles des modules que tu n'avais pas conçu initialement pour ca et que tu découvres en prod que tu passes pas dans un cas non prévu (les test d'intégration etant plus difficiles à mettre en place que les test unitaires) alors que la compilation te l'aurait indiqué dès la phase de dev. La sécurité en devient imparable.
Grâce à ce même typage dynamique, tu en es réduit à utiliser les tests unitaires pour déverminer tes programmes alors que le contrôle de type à la compilation te permet de gagner un temps fou. 2 précautions ne valent mieux qu'une.
Quel développeur qui adopte une programmation defensive n'en est pas réduit à poser des
assert sur le type de la classe attendu.
Du coup certains ont implémenté les interfaces dans des libs non standard.
Tu n'as pas d'attributs ou de méthodes protégées.
Tu déclares tes attributs privés en les déclarant avec __ et tu peux casser aisément l'encapsulation par programme.
Comble de l'élegance, tu dois passer le paramètre self à toute tes déclarations de méthodes.
Tu dois te coltiner des idiomes du langage pour implémenter des structures de contrôles aussi basiques qu'un do while.
Tu peux faire de l'introspection sur tes objets en explorant le dictionnaire qui lui est associé, même si on te le déconseille parce que ca peut changer. Preuve que son modèle objet est figé.
Son héritage multiple est bancal (en profondeur d'abord de gauche à droite) puisqu'il ne résoud pas le pb de l'héritage en diamant de façon élégante comme le C++ (ou en l'évitant grâce à l'héritage d'implémentation simple couplé avec l'héritage d'interface et la délégation comme en Java)
Tu n'as pas RMI en standard
pas de libs standard équivalente aux servlets, aucune spécification commune, ce qui t'oblige à choisir parmi une pléthore de frameworks dont aucun n'arrive à s'imposer.
[^] # Re: Excellente nouvelle
Posté par golum . En réponse à la dépêche Google Web Toolkit sous licence Apache 2.0. Évalué à 3.
Il ne supporte pas l'héritage d'interface et nous vend son duck typing.
Un principe révolutionnaire lorsque tu dois faire de l'intégration de composants, surtout couplé avec son typage dynamique. Lorsque tu assembles des modules que tu n'avais pas conçu initialement pour ca et que tu découvres en prod que tu passes pas dans un cas non prévu (les test d'intégration etant plus difficiles à mettre en place que les test unitaires) alors que la compilation te l'aurait indiqué dès la phase de dev. La sécurité en devient imparable.
Grâce à ce même typage dynamique, tu en es réduit à utiliser les tests unitaires pour déverminer tes programmes alors que le contrôle de type à la compilation te permet de gagner un temps fou. 2 précautions ne valent mieux qu'une.
Quel développeur qui adopte une programmation defensive n'en est pas réduit à poser des
assert sur le type de la classe attendu.
Du coup certains ont implémenté les interfaces dans des libs non standard.
Tu n'as pas d'attributs ou de méthodes protégées.
Tu déclares tes attributs privés en les déclarant avec __ et tu peux casser aisément l'encapsulation par programme.
Comble de l'élegance, tu dois passer le paramètre self à toute tes déclarations de méthodes.
Tu dois te coltiner des idiomes du langage pour implémenter des structures de contrôles aussi basiques qu'un do while.
Tu peux faire de l'introspection sur tes objets en explorant le dictionnaire qui lui est associé, même si on te le déconseille parce que ca peut changer. Preuve que son modèle objet est figé.
Son héritage multiple est bancal (en profondeur d'abord de gauche à droite) puisqu'il ne résoud pas le pb de l'héritage en diamant de façon élégante comme le C++ (ou en l'évitant grâce à l'héritage d'implémentation simple couplé avec l'héritage d'interface et la délégation comme en Java)
Tu n'as pas RMI en standard
pas de libs standard équivalente aux servlets, aucune spécification commune, ce qui t'oblige à choisir parmi une pléthore de frameworks dont aucun n'arrive à s'imposer.
.....