La Pause Café du Forum Programmation

Salut, monde ! :smiley:

Plongé dans l’univers merveilleux des Web Services ! :fou:

Moi dans celui d’envoi de mail dans Workshop. J’ai accès à Javamail v??

Le truc c’est que je fais du multipart/related, et que monsieur envoie la partie mail en html en Content-Transfert-Encoding = 7bit, et ça plante derrière (surtout qu’au passage j’ai de l’utf-8, etc).

Normal pour une pieuvre non ? :paf:

C’est limite trollique ça, heureusement que tu as complété avec tes mots de geek qui veulent rien dire pour débutants :wink: !

Le problème n’est pas d’utiliser ou pas un tableau ou un objet, c’est juste que le tout objet n’est pas adapté en PHP. Faut prendre conscience du fait que PHP relance le script à chaque fois qu’il y a une requête.

Donc il recrée une partie des objets inutilement, ce qui appelle un constructeur, un destructeur, crée une table des symboles, associe à l’objet un ensemble de méthodes - la vtable, qui a un coût mémoire, et qui fait qu’en C++ tu en as pas par défaut (si j’ai bon souvenir, c’est avec le mot clef virtual que tu change ça, etc, etc).

Un tableau, c’est juste une table de hash.

Ah et j’allais oublié un autre truc : tu ajoute derrière la notion de visibilité, donc tu dois vérifier que le champ est public pour y accéder, sinon pan dans les dents.

En Java, c’est moins un problème d’une part parce que compilé, d’autre part parce c’est le compilateur qui gère tout l’aspect visibilité (bon si tu mets une politique de sécurité par contre … )

Donc voilà, l’objet oui. Mais pas partout :slight_smile:

Ok, je comprends, mais les quelques dev’ de php que je connais codent en classes. Perso, je m’en suis servie qu’une seule fois du “principe” en utilisant DOM (et encore pas sûr que vous classiez ça dans la rubrique classe).

Donc j’aimerais savoir quel est le principal atout des classes (ok on va me renvoyer vers le manual mais j’aimerais l’avis d’utilisateur :/) sachant qu’il y a déjà une perte de temps pour les gérer (comme vient de l’énumérer Sans Nom). M’enfin si j’ai bien compris, même si on les utilise pas, PHP construit et détruit :confused: !

Perso je m’en sors pas mal sans, et pour ce qui est de l’associativité je fais des tableaux plus ou moins complexes :confused: !

La perte de temps est minime souvent hein. Mais dans le cas de données en provenance de la BDD, tu n’as pas besoin d’objets car tu n’applique pas de contrôles derrière (voir même, tu le spécialise en fonction de la requête).

L’atout principal des classes c’est tout ce qu’apporte la programmation objet :slight_smile: à ne pas confondre avec les contraintes de performances qu’apporte ces mêmes objets en PHP. ie: c’est génial, etc.

Surtout que l’objet en PHP est jeune, que ça ne supporte pas encore qu’une classe fille implémente une interface implémentée par la classe mère (parce que le connard dev a dit que c’était pas normal, mais c’est pas grave, …), etc.

Perso je fait un mix class/pas class. Et si je pouvais faire en PHP tout ce que je veux en class je ne ferais plus que des class pasque c’est quand meme plus propre au final.

Mais quoi qu’on dise le modele objet de PHP est moche. C’est une espece de copie du modele C++ implementé a l’arrache. Et les classe en C++ c’est déja un peu implementé a l’arrache. Donc ben au final quand on pense en class les language tout objet sont quand meme vachement mieu.

Suffit de cliquer sur le petit lien pour suivre :wink: !
+1 => Incrémentation, après c’est le forum qui gère, pas l’humain :slight_smile: !

Merci pour vos réponses, je comprends mieux le principe, donc pour l’instant on va coder sans :confused: !

Voilà :slight_smile:

Enfin, ils ont quand même repris la syntaxe de Java, l’essentiel est sauvé :slight_smile:

Mais ils sont tellement bêtes qu’ils ne reconnaitront pas leur erreurs (cf. cas de l’interface que j’ai foutu en bug, mais bref).

Le pire dans tout cela, c’est qu’il faut bien qu’ils se démarquent du Java, alors pof on copie le C++ :slight_smile:

(ceci étant dit, si tu n’as pas de Machin.X ou $foo.y c’est normal, vu que . sert à la concaténation)

[ah par contre le C++ permet de redéfinir les opérateurs contrairement à certains langages, puis en plus tu as une vraie notion d’objet constant]

DarKChAm> ok;)
Mandarounet, faut pas le prendre comme ça: PHP est très bien pour ce qu’il est fait: notamment le plus facile à héberger. :slight_smile: en java, c’est franchement pas ça…

Après, on peut dire que c’est une question de volume, mais aussi de cout.

Hum… C’est pas un peu le rôle des fonctions utilisateur d’être réutiliser aisément? (Je cherche à trouver ce qui pourrait me forcer à me lancer dans l’objet :/)

Quand vous voyez qu'on vient de cette daube de PHP 4 et qu'on est dans un langage de SCRIPT pour faire du WEB, je trouve ça très bien. Après je vois pas vraiment le côté C++ (mais ça doit être moi, j'en ai pas fait beaucoup), c'est surtout du Java.

Oui :slight_smile: c’est justement pour ça que j’ai abandonné PHP4. La syntaxe est loin de C++ (même mots clefs qu’en java en fait), mais les constantes de classe sont un exemple de ce que tu as en C++ (ça me dérange aucunement, sauf que bon autant y aller avec des attributs “final”, non modifiables), l’opérateur :: vient du C++, idem pour ->, mais c’est normal vu le langage (. est déjà pris, et ça facilite la recherche malgré tout ce qu’on en pense)

Pour le bug, essaye ça :

interface I {
  public function f();
}

class A implements I {
  public function f() {return 'f';}
}
class B extends A implements I {
  public function f() {return 'f';}
}

Ca peut paraitre stupide, mais ça veut juste dire que B implémente I, sans se préoccuper du fait que A le fait. En Java, ça marche. En PHP, ça plante. Et les devs me disent que c’est stupide de faire ça (ou dans le genre).

Alors que non, ça peut être parfaitement logique point de vue conception (d’autant que si tu étend A sans que A implémente I, et que tu n’implémente pas f, ça marche…)

(oui c’est pas un bug du point de vue des devs de PHP mais bref)

:MDR Je suis pas énervé, t’en fais pas !
Mais c’est intéressant comme débat alors je réponds, même si j’ai pas le temps…

Sans-Nom > OK je vois.
Le “d’autant que” est tout à fait normal, c’est le but des interfaces. Les utiliser seulement quand t’as besoin de garantir une cohérence entre tes classes. Après, le fait de réimplémenter la même interface que la classe mère, je pense qu’il te prévient simplement pour éviter une erreur de conception.
Tu peux me donner un exemple où tu peux pas faire autrement que de réimplémenter l’interface ?

Nul part :slight_smile:

C’est juste dans l’hypothétique cas où ta classe mère est changée pour ne plus implémenter l’interface, ça fonctionne encore quoi…

Apres je dis pas que PHP c’est pas bien. Mais son modele objet n’est pas aussi stable que les vrai language objet c’est tout (et je suis aussi d’accord que PHP a fait un gros bon en avant avec le 5).

C’est juste pour signaler a Darkcham que c’est pas la peine d’essayer de reflechir en tout objet en PHP. C’est pas fait pour. Par contre savoir faire des classe pour faire les base de ton site c’est interressant. Ca permet comme dit madarounet l’avantage de coder en Objet ce voit surtout sur les gros projet. Car comme ca tu peut avoir une personne qui s’occupe de faire des brique propre commune a tout le site et apres les autre code par dessus. Ca permet qu’une seul personne connaisse la globalité des classe commune, les maintiennent et les fasse evolué, ainsi on evite que ca parte en sucette dans tous les sens. Et les gens qui se servent de ces classe font normalement des trucs propre si il réutilise les classes, et reste dans le meme cadre.

Conseil du jour: pour faire un rapport de stage, récupérer le cachier des charges ça comble énormément de blanc :smiley:

C.Q.F.D. :o

Lapsus, les rapports de stage, c’est à chier :o

Pléonasme :neutre: