Commentaires de news :
Mise à jour du tutoriel PHP

+1 sur cet exemple, Zulon.

Le gros problème c'est qu'on peut difficilement parler de règle générale, c'est plus du cas par cas. Là par exemple c'est effectivement la condition ternaire qui est nettement plus lisible, ou pour des conditions enchaînées le switch.

Thenderseb : nous au moins on échange nos idées, nos façon de faire, pas comme toi qui reste à l'extérieur du débat.

Citation : Darth Killer

Oui, et je ne veux pas y rentrer. J'aime déjà pas trop le PHP et j'y connais rien en POO PHP (et je en compte pas m'y intéresser de sitôt). Je vous lis, mais je vous laisse patauger (et ça me fait marrer )

EDIT :

Citation : Zulon

Je mène au même endroit que vous, au milieu de nulle part

Citation : Zulon


Les opérateurs ternaires ne sont pas très simples à analyser donc le code devient moins lisible quand il y en a... CQFD

Moi pour ma part, à la description que vous en faites, j'utilise la POO comme un débutant mais je ne m'en cache pas .
Je trouve, pour moi que j'arrive mieux à m'y retrouver avec la POO maintenant bon je ne suis pas contre apprendre toutes les subtilités de cette manière de coder

Citation : DHKold
Ah, j'utilise des concepts de l'orienté objet, mais lesquels ?
J'utilise ces concepts :
- fonctions
- namespace pour séparer les fonctions manipulant les complexes des autres
- abstraction de données (la méthode create() a pour seul et unique but d'abstraire la représentation des complexes)

Et que je sache, aucun de ces concepts n'est à imputer à l'orienté objet. Evidemment si vous attribuez toutes les pratiques intéressantes à l'orienté objet, pas étonnant que vous le placiez comme le truc ultime qui poutre tout..

Citation : woufeigh
Et qu'appelles-tu "normalisation des variables" ?
Les opérateurs ternaires illisible ? T'as fumé quoi ? Si j'avais commencé à en imbriquer l'un de l'autre ok, mais sans imbrication, avec une condition et une dans expression aussi simple, faut vraiment être con pour pas savoir le lire.
Class mal imaginée ? Possible, j'ai fais ça en 2 minutes. Mais en quoi est-elle mal imaginée ?

Citation : Darth Killer
Aucun rapport avec l'orienté objet..
Un fichier pour mon namespace, un fichier pour ma classe. Il me suffit de regarder le nom de l'objet ou du namespace pour trouver la fonction.
Comme l'a dit bluestorm, faudrait arrêter de tout mélanger, une bonne séparation et organisation n'est pas réservée à l'orienté objet.
Encore une fois, pas étonnant que vous placier l'orienté objet comme le truc ultime qui poutre tout si vous lui attribuez tous les trucs intéressants.

Citation : ThunderSeb
Ce genre de truc est utile, ça montre que certain n'ont pas le moinde idée de ce dont ils parlent. Quand on entend certains dire que la surcharge d'opérateur est réservée à l'orienté objet, on ne peut que rire (ou pleurer, au choix).

Citation : woufeigh
Mais bien sûr. Et qui donc a établi cette vérité ? Les ternaires sont très simple à utiliser si on ne les alambique pas volontairement.

Citation : entwanne

php n'a rien de fonctionnel... c'est procedural...

en php on a pas de pointeurs, mais on a des passages de variables par reference, ce qui veut dire que la remarque precedente qui disait genre "on a pas besoin des pointeurs, au pire, si on veut renvoyer plusieurs variable, on renvoie un array" est injustifiee, puisque les pointeurs, dans ce cas, en C, servent a passer une variable par adresse, et ca, en php, c'est possible.

sinon, les namespaces arrivent en php6.

ce que je constate, c'est qu'apparement, ici, ceux qui gueulent sur l'OO sont ceux qui n'en font pas en php. voir pas de web du tout, ils viennent ici faire la propagande de leur langage, ou comme poulet, flinguer php, mais c'est hors de propos... le debat initial etait : un tuto : php OO ou pas ?

l'OO de php5, est a peu pres aussi puissante que celle de java (aux namespaces pres, mais php6 rectifiera le tir)

les deux langages presentent de l'heritage, de l'interfacage multiple, les public, protected, private, les static et non static, les const, et meme le typage pour le passage de parametres en php... Les deux ont un systeme d'Exceptions assez performant.

ce qui manque a php : on ne voit pas au prototoye d'une fonction ce qu'elle peut throws, contrairement au java, ce qui rend moins lisible ce qu'on peut catcher. Et le type de retour des fonctions.

ce que php a de plus que java : les streamers

je crois que l'OO de php n'est plus seule a remettre en question... ceux qui gueulent sur le fait que l'OO en php ne soit qu'un addon, doivent considerer que l'addon rend a php les memes possibilites que le java...

Citation : coucou747
Les namespaces sont ajoutés avec PHP5.3 et n'ont rien à voir avec l'orienté objet. Et si je me souviens bien, il n'y a pas de namespace en Java.

Pour le prototypage complet, rien ne t'empêche de le faire même si c'est pas prévu.
Juste avant la déclaration de la fonction, j'ai des commentaires sur cette fonction qui donne le prototypes complet (type et signification du retour, visibilité si OO, paramètre + type, rôle de chaque paramètre, exceptions que la méthode peut lancer et qq autres trucs).

Citation : Zulon
Oui, une bonne classe Complexe ne surchargerait que les opérateurs d'assignements, le reste étant surcharger hors de la classe, car n'étant pas propre à un objet en particulier...

a += b; //Operateur interne
c = a + b; //Operateur externe

Code : PHP - Afficher / masquer les numéros de ligne
Hum, d'abord, je place pas la POO au dessus de tout. Ensuite, non, je n'attribue pas toutes les pratiques interressantes à la POO. Mais la POO ne fait justement "que" regrouper de nombreux concepts... Je suis sûr que tu pourrais faire en préocédural l'équivalent de 'héritage et du polymorphisme. Et dans l'absolu, ces concepts ne sont pas non plus restreints à la POO.

Il n'y a dans une voiture aucun concept qui lui soit propre, aussi bien la motorisation, l'utilitaire, le concept de transport, les roues, etc sont des concepts utilisés depuis des millénaires. Je pourrais donc prendre tous ces concepts séparements et les assembler en prétendant que ce n'est pas une voiture. Mais ca serait un peu hypocrite non?


'fin, à première vue je dirais qu'on est mal barré, personne ne veut changer d'avis Moi je resterai persuadué que l'OO a des avantages dans certains cas...

if(cond){
action
}

se traduit de manière très naturelle par :

si la condition est remplie alors on fait l'action

alors que ca
x >= 0 ? x : -x

se traduit pas du tout de manière naturelle

Quand à la normalisation des variables, on commence déjà par choisir des noms de variables intelligibles...

Citation : DHKold
Si PHP proposait la surcharge d'opérateur et l'amitié, c'est que que j'aurais fait.

Citation : DHKold
Le polymorphisme et l'héritage n'ont-il pas été introduit justement par l'orienté objet ? Ce sont donc des concepts propre à l'orienté objet.
Les namespaces n'ont pas été introduit pas l'orienté objet, ce ne sont donc pas des concepts propre à l'orienté objet.
Après qu'on puisse ou pas simuler des concepts d'un paradigme dans d'un autre, c'est une autre question.

Citation : DHKold
Une voiture n'est pas un ensemble de concept mais un concept qui se base sur d'autre concept, tout comme une classe est un concept qui se base sur d'autres concepts, tout comme une fonction est un concept qui se base sur d'autres concept.
Si tu construits un truc dont le concept est "voiture", c'est une voiture et ce quels que soit les concepts sous-jacents à cette voiture.

Citation : woufeigh
Ca se traduit comme ceci : expression = (x si x >= 0, -x sinon), ce qui est tout à fait naturel à mes yeux et aux yeux de beaucoup. Maintenant si ça ne l'est pas pour toi, c'est ton problème.

Citation : woufeigh
En mathématique, appelles-tu tes variables "complex" ou "complex1" ?
Dans Complex::__constuct et Complex::create, on a $real et $i. Si tu comprends pas que $real se réfère à la partie réelle et $i à la partie imaginaire, on ne peut rien pour toi.
Dans Complex::add, on a Complex $c. Si tu ne comprends pas que c'est un nombre complexe, on ne peut rien pour toi.
Dans Complex::sum, on a $a et $b, si pour toi faire a+b est logique en math, alors pourquoi ça ne le serait pas ici ?
Et dans Complex::toString, on a le même $c que dans Complex::add, mais je suis d'accord qu'avec l'absence de typage, $complex aurait été plus adapté.

Et si tu parles de $a dans les deux cas, c'est vraiment de la connerie. Ce n'est pas comme si j'allais utilisé ces code ailleurs que dans l'exemple.

Haku => j'ai pas dit qu'une bonne organisation était réservée à la POO. Nous avons chacun nos façons de penser, de nous organiser, nos méthodes pour y arriver. Pour ça que, comme je l'ai dit à Thunderseb précédemment, je considère ce débat comme un échange d'idées et de façons de procéder enrichissant pour tout l'monde.
Pour moi (c'est subjectif, je sais) la POO est le moyen le plus simple d'esprit de bien s'organiser, c'est tout. D'où ma "révolte" quand on me dit que la POO n'a aucune utilité.

Citation : Thunderseb
Alors toi, tu dis toi-même que tu n'y connais rien, donc tu ne peut pas juger sur l'utilité de notre débat, encore moins dire qu'il mène nulle part. Si tu veux intervenir dans le débat, poste utile, propose des solutions, etc... Merci d'avance.

Ma remarque était à la base basée sur un peu d'humour, mais tu ne sembles pas l'avoir compris.
Et si je peux juger l'utilité du débat. Je vois que vous campez tous sur vos positions, que vous ne parlez pas des mêmes choses et que vous faites une généralité de ce que vous pensez. Donc, comment voulez vous avancer ?

Bon, allez, j'ai plus d'arguments, tu gagne, la POO ca sert à rien.

(Ce qui ne m'empêchera pas de l'utiliser quand j'en ai envie )

Citation : Darth-killer
Ah bon ?
Je te cite :
Citation
Citation

Citation : DHKold
Et peux-tu me dire quand et ou j'ai dit que l'OO était inutile ? ..
J'aime beaucoup ce paradigme et je l'utilise bien souvent.

haku, en java t'as les packages, ce qui correspond a peu pres aux namespaces...

ensuite, pour le prototypage complet, c'est pas ton compilateur qui te dit "ici, il peut manquer un try" en php, c'est dans ce sens que selon moi, c'est un manque...

apres, c'est sur que comme je doxygen bah du coup, ces informations sont presentes... mais si j'en oublie une, bah c'est la merde

Depuis le début, tu crie haut et fort qu'un code en procédural est tout aussi lisible, cohérent et logique qu'un code en OO.

Quel serait donc l'interret d'avoir un paradigme qui n'apport ni une meilleur lisibilité, ni une meilleure cohérence, ni une meilleure logique?

Le but avoué de l'OO était, à la base, de rendre justement plus cohérent la représentation et le traitement d'entités. D'ou la mise au point des concepts tels que l'héritage, le polymorphisme, et autre. Ces concepts n'ont PAS d'autre but que la cohérence/logique. Dès lors que tu prétends que ces concepts n'apportent pas plus de cohérence, ils n'ont plus de raison d'être.

A moins biensûr que ces concepts aient été détournés de leur but initial, ce dont on ne m'a pas prévenu?!?

Citation : coucou747
En effet, je n'avais pas pensé aux packages.

Pour le reste, je suis d'accord bien que je ne considère pas ça comme un manque "vraiment important" (et puis si on utilise set_exception_handler(), il n'y a aucune chance qu'une exception nous échappe).

Citation : DHKold
Oui, et je le réaffirme volontiers.

Citation : DHKold
Permettre de penser différement ? Permettre de répondre à un problème en utilisant le paradigme qui nous est le plus familier ?
Si on prétend que l'orienté objet est inutile, alors on peut prétendre que bon nombre de paradigmes sont inutiles.

Citation : DHKold
Le but d'un paradigme n'est-il pas d'apporter de nouvelles façon de formuler la réponse à un problème ?
D'une façon qui correspond le plus à la façon de penser qui nous est la plus familière ?
Si c'est là le but d'un paradigme (et j'aime à croire que c'est le cas), alors l'orienté objet est tout à fait légitime et utile.

Citation : DHKold
Si c'est le cas, on ne m'a pas prévenu non plus.

coucou747> J'ai assez fait de Python pour savoir ce qu'un langage mal pensé dès le départ peut faire de la POO, et ce que ses utilisateurs peuvent également se mettre à imaginer .

Citation : iPoulet
Et en quoi PHP est mal pensé ?
Et en quoi le modèle objet de PHP en souffre ?
Eclaires nous donc !

Citation : Pas de titre
La façon la plus familière et naturelle de penser ne me semble pas être l'OO. J'aurrais même tendance à dire que l'OO demande un certain entrainement.

Soit, reprenons plus avant. Quel serait l'intérêt de trouver de nouvelles façons de penser (en introduisant de nouveaux paradigmes), si ce n'est pour accroitre la logique inhérente à un code?

Parce que si je suis ton raisonnement, l'OO, qui découle de recherches, aurait créé une nouvelle manière de penser (et non l'inverse), qui au cours des 48 dernières années, serait devenue familière, et justifierait donc l'utilisation de ce paradigme.
On en vient à se demander, en quoi ca aurrait changer quoi que ce soit de ne pas créer ce paradigme:

Pas de POO -> pas de nouveau mode de pensée -> pas de nécessité d'utiliser ce paradigme.

Je me base biensur sur le fait que l'OO n'est pas une manière de pensée que l'on développe de manière naturelle, mais bien un ensemble de concepts à apprendre.

Je ne suis pas d'accord avec toi. Je pense justement que la façon la plus naturelle de se représenter les choses est l'orienté objet.
Quand on voit une chaise, on se dit "elle est brune", on voit donc implicitement une propriété de l'objet.
Quand on voit une lampe et qu'on l'allume, on voit implicitement une fonctionnalité (méthode) de l'objet.

Après, la plupart des concepts sous-jacents (polymorphisme, encapsulation, etc.) sont peut-être incompris ou ignoré (quoi que pas forcément, tout le monde est d'accord pour dire que "un carré est une forme géométrique caractérisée par 4 côtés de taille égale"), mais le fondement de l'orienté objet, la base de la base est là : on voit un objet, un objet qui est caractérisé, un objet qui peut faire des choses si on l'utilise.
Le monde qui nous entoure est fait d'objet, d'objet qui ont des propriétés, qui ont des fonctionnalités, qui sont utilisés, qu'on fait interagir. Et n'est-ce pas là le fondement de l'orienté objet ?

Ainsi, je pense que les recherches ont justement eu pour but de transposer cette vision d'un monde d'objet dans les langages de programmation et d'apporter une formalisation des concepts sous-jacents.

Bon, ça m'énerve alors je vais intervenir, spécialement pour DHK. Avec des roues, un moteur et le concept de transport, on peut faire une moto si on veut et ça en fait une voiture pour autant ? Avec du polymorphisme, de l'abstraction et de la séparation en ensembles cohérents, je te fais un langage fonctionnel, un scheme, un caml, etc. Et c'est de l'objet peut-être ? Il y a les matériaux, les pièces, et la manière dont on les assemble.

L'objet choisit de privilégier la représentation des programmes informatiques sous la forme de réseaux d'entités appelées objets, responsables d'elles-mêmes, et capables d'échanger entre elles des messages. Pour cela, elle emprunte certaines méthodes et concepts existants. Ce ne sont pas ces mêmes principes qui ont engendré l'objet, il y a une grosse nuance, là, nuance que tu dois connaître depuis le temps que tu codes et que tu sembles passer à la trappe un peu facilement, n'est-ce pas un peu... hypocrite ?

Le procédural impératif choisit de représenter les programmes informatiques sous forme d'enchaînements d'actions à effectuer sur un jeu de données. Il emploie pour cela des principes qui recoupent certainement ceux de l'objet. Alors, forcément, il va y avoir des bouts qui vont ressembler, de près ou de loin, d'un paradigme à l'autre, ça ne fait pas des uns des héros et des autres des sales « copiteurs » ; car malheureusement pour les fanatiques de la mode objet, les autres paradigmes n'ont pas eu la bonté de crever à vos pieds pour laisser pleine place à l'objet tout puissant.

Les principes existaient avant, et à t'entendre, on croirait qu'un jour un illuminé s'est dit « tiens donc, mais en fait tout ce que l'on connait déjà, on va l'appeller POO pour faire joli ». Faudrait pas prendre les gens pour des buses.

Je ne suis pas un fanatique de l'OO, et je ne cherche ni à le diviniser, ni à diaboliser les autres paradigmes. Mes arguments étaient mal choisis, je vous le concède, et je m'en excuse. Je concède aussi que tout paradigme peut être cohérent.

Mais je pense toujours que pour produire certains programmes, on peut tirer plus d'avantages de certains paradigmes que d'autres :/

Citation : DHKold
Et là je suis bien d'accord avec toi.
Je pense que tous les paradigmes peuvent résoudre tous les problèmes, mais que dans certains cas, certains paradigmes seront "plus à l'aise" en fonction des concepts fondamentaux qui les composent.

Citation : DHKold
Oui ça doit être effectivement le cas. ( déjà énoncé plus haut par haku ).
Certains problèmes peuvent être plus facilement abordable par la POO. ( mieux visualiser comment interagir par exemple ).

Edit : grillé

mateo, je dois admettre que de tout les zeros que j'ai vu passer sur phpcs exposer leurs oeuvres, j'en connais pas beaucoup qui sont capables de faire de l'OO en l'etat actuel des choses...

tu leurs apprends tous a recopier les exemples de tes tutos, mais tres peu savent aller beaucoup plus loin de leurs propres ailes, suffit de lire le forum pour le voir

Citation : `Haku

Attention au danger lié à cette méthode de pensée.

D'une part, la POO ne modèle pas le monde réel, elle modèle notre conception de ce monde réel. Il n'y a absolument pas d'évidence physique (ou même philosophique) que "brun" soit une propriété de "chaise"; par contre, il est vrai que tu peux penser à ce que tu vois comme une chaise, tu peux en penser qu'elle est brune, et tu peux mentalement te représenter ces pensées sous une forme que la "propriété" d'une instance "chaise" représente assez bien en POO.
Ça se voit beaucoup mieux quand on fait de l'héritage : est-ce que dans le monde réel cela a du sens de dire qu'une "chaise" hérite de "meuble" ? Non, c'est ta vision de la chaise : dans ta tête, une chaise est une sorte de meuble.
Je prétends donc que cette vision séductrice "POO et monde réel" est en fait "POO et ma représentation du monde réel", et qu'en particulier elle n'est pas indépendante de la culture du programmeur, ni de son point de vue sur le problème rencontré, ce qui est encore plus gênant : on peut aborder un problème d'un grand nombre de points de vue, et donc il existe de nombreux schemes objets légitimes pour chaque pas, et non pas une seule structure "naturelle".


D'autre part, la portée de ton argument est en fait assez limitée. Il est vrai qu'à une certaine échelle d'expérience physique, la POO est assez efficace pour décrire notre vision du monde réel. Mais dès qu'on gagne ou en perd en abstraction, les avantages de la POO sont beaucoup moins évidents et ses manques se montrent. Imagine qu'au lieu de représenter une chaise brune, tu veux représenter "le processus de fabrication d'une chaise", le paradigme objet est déjà beaucoup moins percutant.
Ce que je dis est clairement une évidence : la POO n'est pas efficace partout, et tu le savais déjà. Mais j'affirme plus encore que la programmation est en fait assez portée sur le changement de niveau d'abstraction, et que donc ces problèmes se rencontrent concrètement en programmation. Par exemple, un grand nombre d'applications manipulent ce qu'on peut décrire comme un "langage" : les compilateurs, interpréteurs, parseurs, moteurs d'affichage, convertisseurs, etc., manipulent des 'langages'. Je prétends que la POO n'est pas efficace pour représenter ce type de concepts (contrairement à ton exemple de chaise), que (par exemple) un paradigme fonctionnel sera souvent plus adapté dans cette situation, et surtout qu'on rencontre cette situation "souvent".

D'ailleurs, je pense qu'une partie des problèmes qu'ont aujourd'hui les programmeurs POO avec les "design patterns" viennent de là : les design patterns sont typiquement des tentatives de faire de la POO à différents niveau d'abstraction, et ça marche pas super bien.

Citation : bluestorm
En effet.
Citation : bluestorm
J'irais presque jusqu'à dire que c'est totalement dépendant du programmeur, de sa vision des choses, de sa culture, de son expérience, de son enseignement.

Citation : bluestorm
Et je suis d'accord avec toi. Un sujet sur developpez.com parlait d'analyseur et de résolveur d'équation mathématique et les codes fonctionnels étaient plus "simple" que les procéduraux ou les objets.

Bonsoir,

À de nombreuses reprises dans ce topic, il a été soulevé la difficulté du paradigme OO : pour autant que je sache, Alan Kay est un fanatique des méthodes d'éducation et d'éveil de l'enfant, et il a testé très tôt Smalltalk (le premier langage OO) avec ... des enfants .
Après, je dois reconnaître que la principale difficulté de ce paradigme réside dans l'organisation des classes, mais bluestorm l'a déjà évoqué (cela dit, en pratique, les questions philosophiques sur la couleur des chaises, on s'en tape).

Citation : `Haku
Si on passe sur les problèmes de typage de PHP, sur la cohérence toute relative dans les noms des fonctions, l'absence (jusqu'à présent) de namespace et l'intégration tardive (et donc peu intéressante) de la POO, je pense que le principal reproche que l'on peut faire à PHP est de ne pas satisfaire sa mission (créer des sites web d'une manière simple). En effet, quand on observe un peu les alternatives, on constate que le seul avantage de php est d'avoir une syntaxe proche du C, mais certainement pas d'être accessible. Coder correctement en php, ça demande beaucoup trop de boulot pour des résultats passables.

Il existe un certain nombre de plateformes de développement web qui innovent pour chercher des solutions adaptés à internet (on citera par exemple les continuations, l'intégration transparente avec javascript, xml, sql et la parallélisation).

Par ailleurs, pour ta culture, le polymorphisme vient du fonctionnel... et l'OO pur a été bâti sur le lisp et dispose donc des fonctions anonymes, ce qui lui permet d'éradiquer les phrases impératives (typiquement, les conditions, les boucles ainsi que de nombreux design pattern) de sa syntaxe. Au même titre que Java, PHP devient un patchwork de paradigmes (sauf que contrairement à Java, l'incohérence est involontaire : au début, c'était un langage impératif limité, et peu à peu, ils y ont greffé des choses à la mode pour combler ses faiblesses ). Bref, c'est un langage qui se déploie facilement mais qui n'apporte rien d'intéressant, en plus de ne pas être fiable.

Si tu es curieux du développement web OO pur, je te conseille vivement Seaside . Je n'ai jamais fait d'objet en PHP, mais je pense que tu aurais des choses à apprendre de Smalltalk, ne serait-ce que pour ta culture, et parce qu'on code toujours mieux avec plus de concepts en main (récemment, j'ai du faire une validation de formulaire en PHP, et j'étais content de connaître le fonctionnel).

Bonne soirée

Citation : lastsseldon
Pourquoi une arrivée tardive de l'OO la rend peu intéressante ?
Certes il n'y a pour le moment que peu d'applications qui en tirent profit, mais ça vient petit à petit. Divers outils comme les framework, les orm, etc. commencent également à arriver.
Et dans le contexte d'applications complètement orienté objet (voir Prado par exemple), le type hinting suffit presque toujours bien qu'il soit dommage qu'on ne puisse pas typer les primitifs.
Citation : lastsseldon
Tout dépends de ce que tu appelles "créer un site web". Si tu attends un site professionnel avec un code en or, c'est évident qu'il faut un gros travail. Mais si tu attends un simple site qui fonctionne, qui ne souffre pas de faille de sécurité, c'est faisable très facilement.

Citation : lastsseldon
Je vais aller consulter cela, merci.

Citation : lastsseldon
En effet, je l'ai appris en cherchant l'origine des concepts de bases de l'OO, chose que j'avoue n'avoir jamais fait jusqu'à hier.

Citation : lastsseldon
J'irai voir cela, mais je pense que tu devrais t'intéresser à l'OO en PHP avant d'en juger (regardes Prado par exemple).
Pour ta validation de formulaire, je ne connais rien au fonctionnel (j'ai juste suivi les premiers chapitres d'un tuto de base d'OCaml) et pourtant j'utilise une technique similaire à la tienne depuis bien longtemps.
D'ailleurs tu devrais utiliser des références pour éviter de copier des variables inutilement.