Éric a écrit 4850 commentaires

> C'est juste un "branding" de Firefox. Donc ca n'apporte rien.

Fut un temps où justement Mozilla demandait à ce qu'on ne distribue pas son browser sur CD mais au contraire qu'on "l'endosse" en changeant le nom, les splash screen et tout ça avant de le faire. On avait d'ailleurs a cette période eu des jolis slapsh carrés oranges vides pour forcer les gens à endosser le logiciel au lieu d'en laisser la responsabilité à Mozilla.

Je ne sais pas si cette politique a changé avec l'arrivée de firefox et la nouvelle fondation, mais on peut difficilement reprocher aux gens de faire ce qu'on leur demandait il y a encore peu.

Alors n'hésites plus. Regardes le contenu de la bible, elle n'est pas vraiment à jour coté PHP5. Si c'est entre ces deux là que tu hésites ton choix devrait être facile.
Globalement les bouquins PHP5 actuels sont soit des bouquins PHP4 pour lesquels on a changé le n° en rajoutant un ou deux paragraphes PHP5, soit des livres parus il y a quelques temps et qui ne sont pas à jour avec les évolutions de PHP5.
Du coté de ce qui est présent en librairie à ce jour tu peux arrêter d'hésiter et prendre direct le livre le cahier du programmeur.

Si tu hésitais parce que un bouquin avec une orientation "gros bouquin référence", je te suggère d'attendre une dizaine de jours. Tu auras "PHP 5 avancé" (collection blanche des éditions Eyrolles) qui sortira à ce moment là. Je ne suis peut être pas très objectif vu que je suis un des deux auteurs mais ils me semble beaucoup plus à jour sur PHP5 que les autres bouquins de la même catégorie. (*)

En précommande à la FNAC, en attendant la description sur le site d'Eyrolles : http://www.fnac.com/Shelf/article.asp?PRID=1524632(...)


(*) et ce n'est pas peu dire, quand je vois le bouquin d'Atkinson qui est basé sur les premières versions de dev du début d'année dernière ... l'essentiel de ce qu'il décrit a changé ou n'existe plus, et inversement beaucoup de choses n'existaient pas encore.

les balises [b] et [i] existent toujours , même en xhtml 1.1

quand à tout ce qui n'est pas présent en xhtml 1.0 strict, ce n'était déja pas présent en html 4.01 strict. *Rien* n'a disparu entre HTML 4 et XHTML 1, aucun élément. XHTML 1.0 est une reformulation en syntaxe XML sans *aucun* changement au langage..

Non, th c'est pas pour mettre en avant, c'est pour symboliser une cellule d'entête (certes, normalement on met les entetes en avant, mais ce n'est pas réciproque)

Les connexions aux BDD persistent (enfin si tu ne marches pas en CGI qui arrête le processus à chaque page), ça depuis pas mal de temps (les fonctions *_pconnect())

Tu peux sauvegarder tes objets en les sérialisant (sur le disque, en mémoire, peu importe). C'est clair que c'est moins élégant que ce qui existe en java (surtout parce qu'on recharge toutes les définitions de classe à chaque fois) mais ce n'est pas trop le problème.
Ce qui fait la différence dans java ce sont plutot les mécanismes de synchro, de transaction, les objets partagés ... maintenant, est ce que
c'est forcément quelque chose de nécessaire pour 80% des applis ?

> Dans tous les cas, php n'est pas un langage objet à proprement parlé.
> Il lui manque des notions essentielles [..]

Ce qui me gêne c'est que les notions essentielles dont tu parles n'ont rien de nécessaires pour un langage objet, d'ailleurs la persistance n'a rien de spécifique à la POO non plus.
PHP n'est pas java, on le sait, mais mis à part ça ...

Le mien (Siemens) il fait même réveil quand il est éteint (sisi, quand j'éteins ça ne coupe pas les alarmes, et ils se réveille à la première alarme programmée)

Oui et non. Le problème ne venait pas de la licence de PHP mais de la licence du composant principal utilisé : le moteur Zend. Il était modifiable, distribuable mais il y avait un truc qui la rendait non libre.

Ces problèmes ont été résolus il y a pas mal de temps. PHP et ZendEngine ont maintenant des licences tout à fait libres (et reconnues comme telles). Par contre elles ne sont pas compatibles GPL (et ça n'arrivera probablement jamais vu la mauvaise opinion de la GPL qu'on les développeurs PHP)

La non compatibilité GPL est d'ailleurs la source d'un événement majeur avec PHP5 : la librairie cliente MySQL (je parle bien de la lib, pas de l'extension PHP) ne sera plus fournie par défaut comme ça avait toujours été le cas, et du coup ne sera plus compilée par défaut. Mysql AB a en effet rompu la compatibilité de la lib client entre Mysql 4.1 et 3.x, la nouvelle est sous GPL, donc non compatible avec la licence PHP. (ça a été résolu depuis avec une exception dans la licence de la lib cliente mysql mais je doute que la team PHP revienne jamais en arrière concernant son intégration dans la release PHP)

Toutes les nouveautés sont faites pour êtres "facultatives". En gros si tu n'utilise aucune nouvelle extension objet rien ne renverra d'exception.
Il est vrai qu'il est globalement plus simple de tester la valeur de retour que de tout mettre en try/catch dès que tu utilises une fonction. PHP privilégiant la simplicité sur les procédures "académiques" ...

Ceci dit il y a eu il n'y a pas longtemps des discussions pour refaire la gestion d'erreur PHP : attribuer un type d'erreur (pas seulement un niveau) à chaque événément. Après tu peux déclarer ce que tu veux gérer en exception ou en erreur classique. Ça ne sera pas pour la 5.0 mais dans un futur à long terme je pense bien qu'on arrivera à un tel système (parce que l'état actuel est plutot batard, on est d'accord).

Pour le moment tu peux toujours faire un gestionnaire d'erreur standard qui lit le message d'erreur PHP, remarque que c'est un fopen() qui plante et lance une exception. Ça relève du hack mais ça marche.

Pire, SimpleXML ne sait pas faire la différence entre un commentaire et un élément :

[hr] est strictement équivalent à [!-- hr --] une fois accédé par SimpleXML

Reste le problème des espaces de noms qu'ont ne peux utiliser que via des requêtes xpath, des problèmes sur les attributs, de la dualité élément / liste d'élément, de la façon de récupérer le contenu des éléments ...

Bref, c'est utile pour quelques trucs simples vite faits bien faits, mais loin d'être aussi bien qu'on le dit.

> Vaut-il mieux utiliser PHP4

Clairement pas. Leurs méthodes sont proprio, pas toujours finies, et il reste des memleak ou bugs qui ne seront pas corrigés.
Par contre si tu te reposes dessus tu peux être sûr que ça ne changera plus, contrairement à ce qui est indiqué dans la doc.

> attendre PHP5 sachant que le projet ne sera mis en production
> qu'au début de l'année 2005 ?

Pas besoin d'attendre alors, les RC sont déjà suffisament stables pour être utilisées lors des développements. Même avec de gros retards ça sera prêt en 2005.
Le DOM de PHP5 vise la conformité aux spécifications du W3C donc tant que tu n'utilise que des choses qui sont prévues par ces specs, tu ne prend aucun risques vis à vis des possibles évolutions de PHP par la suite.

Perso je te conseille très fortement d'utiliser le DOM de PHP5. Tu peux t'y plonger dès maintenant, l'essentiel est déjà implémenté et fonctionnel (plus que ce qui était fait en PHP4 de toutes façons).
Par contre .. hum ... évites SimpleXML

Des déclarations ont été faites en commun avec Sun, donc c'est officiel de ce coté là aussi.
Si j'ai bien compris Sun doit faire au moins une implémentation tout ce qu'il propose comme spec pour Java, pour prouver que ça marche. Et PHP a été retenu pour ces exemples dans tout ce qui est liaison de Java avec d'autres langages de script.

Perso je ne vois rien venir, la seule chose nouvelle c'est au contraire qu'ils ont cassé la liaison avec Java (possibilité d'utiliser des objets java) qui existait avec PHP4

La force de PHP ce n'est pas d'être aussi complet ou aussi théorique que Java, c'est de pouvoir faire rapidement quelque chose de simple et clean. Ça fait ce que c'est sensé faire : rapidement et correctement.

Je ne taperai pas, c'est probablement moi qui en parlais dans le mag en question (pas taper non plus, faut bien vivre aussi).

> je veux dire c'est beaucoup mieux de réserver le Java pour la
> machinerie et le PHP pour le front-end, c'est mieux que du tout Java
> je pense non

à voir, perso je considère php au même niveau que python de ce coté là maintenant (je ne parle pas du langage mais du type d'utilisation). Il peut devenir un outil assez intéressant : on développe en PHP puis on recode en C par derrière les parties métier très gourmandes quand on a besoin de gagner en perf.
Vouloir s'interfacer avec Java n'est pour moi intéressant que si tes applications sont déjà en Java et qu'il n'est pas envisageable d'utiliser autre chose. Et même là, je me demande jusqu'à quel point il n'est pas alors plus pertinent de tout faire en java (mélanger plusieurs langages ce n'est pas toujours la meilleure solution)

moi je l'aime bien le graphisme par défaut de ma mdk (gnome, j'ai pas testé le kde). C'est clean, ça saute pas dans tous les sens, y'a rien qui attire l'oeil. Pour tout vous dire je l'ai gardé (d'autant que avec celui là si je lance une appli qt ça reste dans le même look'n feel)

pour le middleclick sur l'onglet c'est très perturbateur comme modif, et c'est bien pour ça que c'est désactivé par défaut sous Linux.

Sous Win le bouton du milieu est un bouton "magique", il peut servir au défilement ou à des actions spéciale. Sous Unix il a une fonction bien définie : copier le contenu de la sélection.
Si on ferme l'onglet avec ce bouton on passe d'une fonction créatrice (copie) à une fonction destructrice (fermeture). Pour ceux qui ont l'habitude du comportement Unix ça risque de s'avérer difficile ou au mieux "artificiel".

Tu peux attendre. Le module d'intégration avec Java marchait avec PHP4, il a été cassé avec PHP5.
Pour l'instant les pseudo intégrations avec Java ne sont que des déclarations de principe. Java s'est engagé à utiliser PHP comme langage de référence dans leurs proof of concept de liaison avec les langage de script (si j'ai bien compris toutes les specs Java doivent avoir une implémentation réelle avant d'être considérées comme telles et Java utilisera PHP pour ces implémentations de script en relation avec Java) ... mais pour l'instant on n'a rien. Je dirai même qu'on a plutot régressé (vu qu'avant on avait déjà possibilité d'interagir avec les objets Java)

La sortie finale est prévue pour la première quinzaine de juillet, donc assez rapidement.

> 3 centimes par internaute, ça me paraît inutile

Si je recevais 3 centimes par spam reçu je gagnerai plus de 100euros par mois. Ce n'est pas si négligeable que ça je trouve

à noter que les brevets ont des phases d'étude avant d'être acceptés, où le brevet est public et où chacun peut apporter contestation ou élément à charge.
C'est surtout à ce moment là qu'il faudrait faire des objection. C'est là que c'est fait dans le reste de l'industrie (bon, c'est pas le particulier qui surveille ça, mais les grosses entreprises le font). Sauf que visiblement dans les milieux informatiques soit on s'en fout soit il y a accord pour tout laisser passer (tu fais passer ton brevet je fais passer le mien) ... je ne sais pas.

Là où je me pose des questions c'est quand des gens débusquent des brevets type "double click" juste après leur sortie. Ça veut dire qu'ils suivent l'actualité des publications. Et dans ce cas, pourquoi ne pas faire objection avant, là où c'est prévu dans la procédure ? pour pouvoir dire après "les brevets c'est idiot" ? Il y a un truc qui m'échappe

perso j'en ai un peu plus que toi (je fais entre 75 et 150 spam / jour) et j'ai testé pas mal de choses :

- le filtrage coté client, ça marche assez bien mais on les sens passer les 150 spam, que ce soit au niveau vitesse de téléchargement, réactivité du client mail (quand d'un coup il a 10 mails à télécharger et analyser). Le pire c'est quand il prévient de l'arrivée de mail alors que c'est uniquement du spam.

- un truc qui va scanner la boite imap à distance pour virer le spam à intervalles réguliers. La solution est élégante mais en pratique c'est moins intéressant. Quand je vais sur ma boite je tombe entre deux scan et comme les spam tombent visiblement par lot ça ne change pas grand chose. Pire, visiblement ça entraine quelques dérapages au niveau des clients mails quand un mail disparait entre la lecture du répertoire et la lecture du message : visiblement tous ne prennent pas en compte qu'il peut y avoir plusieurs clients IMAP simultanément. Toujours le même problème pour les outils qui signalent l'arrivée de nouveaux mails. En plus il faut une machine up en permanence pour faire tourner le filtre IMAP (quand je pars longtemps de chez moi j'éteins ma machine perso, et manque de pot c'est là que j'utilise les webmail ou config RTC et que le spam me dérange le plus).

- un scan serveur: sans apprentissage les résultats sont moyens. Ca permet de filtrer une bonne partie mais soit ça fait des false positive, soit ça en laisse passer 20%. Comme de toute façons je ne peux pas me permettre d'effacer les messages (je les met dans un répertoire séparé pour regarder vite fait quand j'ai le temps au cas où un vrai mail soit filtré) je marque les messages. Et là toujours les mêmes problèmes: téléchargement, avertissement de nouveaux messages ... bref, rien de réellement résolu.

J'ai pris une autre option : utiliser une nouvelle boite, garder l'ancienne un an pour faire la transition, ne pas diffuser les adresses de la nouvelle en clair et en public (pour ça jetable.org est bien utile). Je sais qu'à terme le problème se posera aussi pour la nouvelle boite mais à ce moment là ... soit je change à nouveau soit quelqu'un a trouvé la solution à mon problème.

> Mais oui, il fallait bien tester avant de sortir une version officielle.

Les RCs étaient bien là

parce que toi, en voyant que ton lecteur CD ne marche plus tu aurais pensé à faire une relation avec le kernel ? (moi je ne l'utilise pas tous les jours non plus donc je n'aurai certainement pas fait la relation)

Et quand bien même tu te dis "tiens, grillé le jour de l'upgrade kernel" aurait-tu osé penser que les deux étaient liés ? aurais-tu osé faire le rapport de bug ?

Et quand bien même tu aurais été un des rares à le faire (des gens ont testé les RCs, ça n'a pas pour autant soulevé le problème), est-ce qu'un rapport de bug isolé "mon lecteur CD a grillé le jour ou j'ai installé votre kernel" aurait été utilisé ?

Ce sont des trucs qui malheureusement ont beaucoup de chances de ne pouvoir être corrigés que "après les dégats de masse".

> Et après, mandrake a appris une leçon debien pour développer la version 10.

Releaser après tout le monde ? sans vouloir critiquer l'attitude de Debian (c'est très bien, c'est un choix tout à fait respectable), il est un peu facile de critiquer celui qui essuie les platres justement.

Je confirme. Malgré ce qu'on essaie de nous faire croire :
- la SACEM n'a pas le monopole
- elle n'est pas un passage obligatoire
- on peut faire légalement respecter tous ses droits sans passer par elle
- passer par elle n'ouvre droit à aucune rémunération ou aucun droit dupplémentaire (c'est même le contraire vu qu'elle prend un %)
- on n'est obligé de payer des droits à la SACEM *que* sur les oeuvres enregistrées la bas.

il l'a toujours géré. Si tu veux un dossier IMAP dispo hors ligne tu coches droit pour afficher les propriétés et tu actives "rendre ce dossier dispo hors ligne".
Après pour passer hors ligne tu cliques sur "travail hors ligne" dans le menu fichier.

et PHP 5 devrait arriver d'ici un mois - un mois et demi
La RC3 devrait être ces prochains jours

Oui, ils ont sacrément taillé dans le bloc. D'autres petites choses ont été jetées et l'ensemble est beaucoup moins révolutionnaire que ce qu'on aurait pu avoir :
- impossible de dériver correctement la classe d'exception
- les contraintes rajoutées sur le __tostring() le rendent complètement inutilisable

Disons qu'on a quelques modifications très utiles sur la POO, le reste n'a pas énormément avancé, on est d'accord.

Perso j'ai encore une grosse liste de souhaits. Parmi les principaux il y a :
- espaces de nom ou système de package
- respect de la casse pour les fonctions/méthodes (c'est un patch de 5 lignes qui fait d'un coup gagner 20% de perfs à PHP)
- support unicode par défaut