Et bien non !
Les miracles n'existent pas.
Il y avait bien un modèle objet
, mais plus que limité.
Je passerai sur la grosse blague qu'était celui de la version 4, puisque depuis le langage a évolué et s'est amélioré avec la version 5.
Cette capacité d'évolution dans le bon sens
du langage, quand elle se produit, est d'ailleurs l'une des choses qui me fait parfois dire :
PHP, ce n'est pas que de la merde !
Pourtant, il y a toujours des principes de la programmation orientés objet
qui manque à l'appel et qui me font dire régulièrement :
PHP, c'est de la merde !
Actuellement, il y a très peu de choses nativement objet
en PHP.
Il y a bien la SPL, et quelques extensions comme mysqli ou simpleXML, qui proposent une telle interface, mais les types natifs ne le sont toujours pas.
C'est d'ailleurs assez paradoxal puisque les développeurs du langage mettent en avant son modèle objet
pour séduire le monde professionnel et ont la volonté de proposer une alternative crédible à JAVA.
Mais la n'est pas la question...
La vrai question est :
Quel serait l'intêret d'avoir les types natif en objet ?
Je vous aide, la réponse n'est pas 42.
Avec des types natifs objet
, Il deviendrait entre autre possible :
- d'imposer un type sur les paramètres des fonctions et des méthodes sur autre chose que les objets et les tableaux.
- de pouvoir faire du polymorphisme, pour modifier le comportement des types natifs en fonction des besoins ou bien pour générer facilement des objets
fantaisies
dans le cadre de tests unitaires.
Ce dernier point est d'ailleurs celui qui me fait le plus pester car actuellement, simuler ne serait qu'une impossibilité de connexion sur une base de données lorsque l'on ne dispose que d'une ressource est pour le moins délicat
, pour parler poliment.
Cela oblige à encapsuler les appels aux méthodes natives de PHP dans une classe qui sera ensuite utilisée pour générer l'objet fantaisie
qui permettra de simuler les problèmes de connexion.
Rien de bien dramatique à première vu, sauf qu'en y regardant d'un peu plus près :
- cela ajoute de la complexité au code.
- cela oblige le développeur à écrire du code, éventuellement avec des bogues, afin de pouvoir effectuer des tests unitaires justement destiné à empêcher les bogues...
Autant pour ceux qui pensent que PHP est un langage qui permet de développer rapidement, puisque dans ce cas de figure, le modèle objet
du langage oblige le développeur a compliquer son code et à se concentrer sur autre chose que le code métier
.
Alors, peut être qu'un jour, les développeurs de PHP se décideront vraiment à faire de la concurrence à JAVA en implémentant des types natif objet
.
Mais en attendant ce jour, je n'ai pas fini de dire :
PHP, c'est de la merde !
4 réactions
1 De Palleas - 06/11/2008, 14:39
C'est trop facile de dire que c'est de la merde. Mon microonde ne me permet pas de décongeler mes plats selon le type d'aliment comme celui de ma mère peut le faire, donc c'est de la merde ? Non, il est juste plus limité.
Effectivement, le modèle objet PHP n'est pas aussi poussé que celui du Java, ou encore du C++ (encore que le C++, c'est un peu imbranlable, si tu me passes l'expression), mais on y arrivera petit à petit
2 De Laurentj - 06/11/2008, 15:52
>Ce dernier point est d'ailleurs celui qui me fait le plus pester car actuellement, simuler ne serait qu'une impossibilité de connexion sur une base de données lorsque l'on ne dispose que d'une ressource est pour le moins "délicat", pour parler poliment.
hum.. tu devrais jeter un coup d'oeil à PDO..
Pour les types natifs, oui, pourquoi pas mais :
1) c'est un héritage des anciennes versions de PHP
2) avoir un objet "chaine", un objet "nombre" etc plutôt qu'une simple chaine, ou un simple nombre, c'est bien plus couteux en mémoire et en perf. (jette un coup d'oeil aux internals de PHP ou autre langage). Faut pas s'étonner que beaucoup aient critiqué la lourdeur de JAVA (voir de python/ruby) sur les serveurs web. Le "tout objet" a sa part de responsabilité dans ces problèmes de perf/scalabilité.
Bon sinon, arrête s'il te plait de répéter toutes les 10 lignes que PHP c'est de la merde, ton discours n'en sera que plus crédible et sérieux.
3 De gabriel - 06/11/2008, 17:58
que php ne soit pas un langage orienté objet ou objet, c'est un fait. Pleurer sur le fait que l'api php ne soit pas orientée objet ou objet, c'est une perte de temps. Comprendre que le volet orientée objet n'est fait que pour le modèle métier et pas pour l'api est un grand pas dans l'existence.
4 De mageekguy - 07/11/2008, 09:26
@Laurentj
PDO est effectivement une solution possible dans le cas que j'expose.
Sauf qu'utiliser PDO lorsque l'application n'utilisera jamais que mysql, c'est inutile.
Et cela ne résoud pas le problème pour les sockets, les fichiers, les connexion LDAP, memcache, etc.
Concernant l'impact du tout objet sur les performances, je suis à la fois d'accord et pas d'accord.
Je pense d'ailleurs que je vais développer mon point de vue dans un prochain billet.
Quand au vocabulaire que j'emploie, c'est un choix que j'assume pleinement.
Je ne cherche pas à avoir une crédibilité sur la forme, ni sur le fond, d'ailleurs.
Je ne cherche pas à prouver quoi que ce soit.
Je cherche à faire réagir, réfléchir, à faire comprendre certaines choses à certaines personnes.
Peut être que tu as raison et que ma méthode demande des ajustements.
Mais que tu fasses un commentaire sur mon blog me fait penser pour l'instant qu'elle n'est pas si mauvaise que cela.
Après tout, un peu de provocation, surtout lorsqu'elle n'est pas gratuite, ne fait jamais de mal et change du consensuelisme ambiant.