Laurent J a écrit 2951 commentaires

On doit pas avoir les mêmes fichiers man.

- $this qui change quand ça lui plait (dans certains cas, quand on appelle une méthode d'une classe A à partir d'une méthode d'une classe B, $this dans la classe A pointe sur... B)

Tel que tu décris ce processus, c'est tout à fait normal. Ça s'appelle le polymorphisme.

>je ne vois pas l'intérêt de l'objet pour faire la programmation purement "systeme".

L'utilisation ou non de l'objet n'a strictement rien à voir avec le fait de faire de la prog système ou pas. C'est plutôt une histoire de modélisation, d'algorithmie. Il y a eu des OS fait quasiment entièrement en objet (BeOs par ex), cela n'en a pas fait des OS moins bien que ceux programmés en pure C (au contraire même).

exactement, le zend framework se rapproche plus d'une bibliothèque comme pear que d'un véritable framework qui propose normalement un cadre complet de développement, avec des normes de nommage, une structure précise de l'application, tant au niveau des objets que des fichiers.

Cela ne veut pas dire pour autant que le Zend Framework n'est pas intéressant. Mais pour moi il n'a de framework que le nom.

Peut-être devrais tu te pencher un peu plus sur le modèle objet de PHP 5 ? On est loin de celui de PHP3 ou PHP4 hein...

On peut faire des choses très propres en objet avec PHP5.

Certes, il manque peut être quelques trucs par rapport à d'autres langages objets super avancés (namespace par exemple, mais ça viendra dans PHP6), mais le minimum est là et bien là, et suffit déjà largement à faire des trucs convenables. On a pas toujours besoin de l'artillerie lourde des autres langages pour faire un bon soft.

euh... quand mon téléphone est éteint, il est vraiment éteint. J'ai beau appuyer sur toutes les touches, rien n'y fait, il ne réagit pas. Il faut que je l'allume pour téléphoner.

Ce à quoi tu penses, c'est la possibilité d'appeler des secours, quand il est allumé, mais quand tu n'es pas autorisé à accéder au réseau (pour diverses raison, genre tu n'a pas tapé ton code pin, ou que tu es dans un pays étranger mais que tu ne peux utiliser le réseau local parce que tu n'a pas pris un abonnement international :-) etc...)

>C'est bien beau, mais comment on fait pour que tout le monde puisse le voir ?

Bah ils installent un navigateur récent ? Et tant pis pour les autres qui ne peuvent pas.. (l'informatique évolue, il faut peut être un jour arrêter d'utiliser des logiciels obsolètes...)

>l'autre avantage de flash est que c'est compilé en bytecode par la machine flash donc bien plus efficace que js dans un navigateur

Ce ne sera plus un avantage de flash, puisque adobe a libéré sa VM javascript/actionscript (le truc qui lit ce bytecode dont tu parles :-p), et que ce sera intégré dans Mozilla 2/Firefox 4.

Il parait, mais c'est à prendre avec des pincettes, rien n'est sûr, que Firefox 3 implémentera la balise video (il existe déjà une implémentation experimentale, croisons les doigts pour qu'elle soit prête pour la beta de FF3). au pire ce sera dans Firefox 4.

> Quel est l'intérêt pour le consommateur ?

La matière première est certe la même, mais là où les autres fournisseurs peuvent se démarquer, c'est au niveau des services, des offres au niveau abonnement etc..

En toute honneteté (je suis le développeur d'Etna), Etna n'est pas vraiment opérationnel pour être utilisé en production. Il y a des bugs dans le validateur RelaxNg, on ne peut pas utiliser des feuilles XSL etc... En ce moment d'ailleurs je suis en train de refaire from scratch le validateur avec un autre algo.

Bref, not really ready. Mais j'ai bon espoir que d'ici la fin de l'année, je sorte une version qui soit vraiment stable.

>efficace pour se rendre compte de l'activité en temps réel pour un novice

et keskil en nana fout' du temps réel de l'activité, le novice ? surtout pour un super gros projet aussi connu que ubuntu ? franchement ? Je trouve totalement inutile ce rafraichissement toutes les 2 secondes. Encore un truc web 2.0 qui sert à rien quoi... (mais qui pompent des ressources...)

Effectivement, je n'avais pas vu que tu avais mis le namespace XUL sur les balises XUL, dans les exemples. Cependant il y a des attributs non xul qui n'ont pas leurs propres namespaces..

non, dire que c'est du XUL, c'est induire le développeur en erreur, puisque seulement quelques balises de XUL sont utilisées, et que partiellement implémentée. Qui plus est, à ce pseudo XUL, il y est ajouté des balises qui n'ont rien à voir avec le XUL, et qui sont propres à Akrogen.

Ton exemple du C est un mauvais argument. Si tu dis "voici mon programme en C", alors je m'attend à ce que ton programme compile avec n'importe quel compilateur C.

Si je prend un source pour Akrogen, non seulement ça ne va pas s'afficher (ou mal) dans un moteur qui sait interpréter le vrai XUL, mais dans l'autre sens, si je passe du vrai XUL à Akrogen, il y a également de forte chance (vu la faible implémentation de XUL dans Akrogen) que ça ne fonctionne même pas (et pour cause, puisque je n'aurais pas les balises spécifiques à Akrogen).

>Mais Akrogen n'a pas la prétention de ré-implementer Mozilla

Donc ce n'est pas du XUL. Tu ne dois donc pas appeler ça du XUL.

Quand tu veux parler d'une renault megane, tu n'appelle pas ça une 307, bien que ce soit toutes les 2 des automobiles, avec 4 roues, 1 moteur, un volant...

On pourrait dire pareil pour C# ou Java. Ça se ressemble sur certains points, mais on n'a pas appelé ça avec le même nom.

En clair : trouve un autre nom pour ce langage XML.

Cela aurait été bien de ne pas appeler ce langage XML de description d'interface "XUL". Je rappel que XUL est un langage de Mozilla (XUL est d'ailleurs une TM de Mozilla), et le pseudo XUL de Akrogen n'a que quelques similitudes avec le XUL de Mozilla, d'après ce que j'en vois : des attributs et balises propres à akrogen, et une implémentation vraiment très partielle du XUL de mozilla d'après la doc de référence

Bref, cela ne fait qu'apporter confusion chez les développeurs, c'est dommage.

ce que tu décris ressemble fortement à jDao dans le framework Jelix.

Tu as juste un fichier dans lequel tu déclares sur quelle tables et quelles propriétés l'objet dao sera mappé. Tu peux aussi decrire des methodes : nom, type (select, update...), les propriétés à prendre en compte, les conditions etc..

Et jDao te compile tout ça sous une forme de classe PHP, avec toutes les méthodes qu'il faut et que tu as décris, contenant alors les requêtes SQL correspondantes. Cette classe est mise en cache (donc pas de recompilation à chaque appel). le fait que les requêtes soient déjà générée et le code mis en cache apporte des performances respectables pour un orm.

je vois deux gros inconvénients à cette méthode :

1) c'est super lourd. Même pour un petit aquarium comme ça (j'ai presque le même à la maison). Pour le déplacer rempli, c'est galère.

2) changement des pièces /maintenance : faut tout essuyer (l'huile c'est galère à essuyer), surtout les contacts j'imagine, quand on branche/rebranche un truc. Sans parler qu'on s'en fout plein les mains.

une raison pour ne pas prendre une dedibox : ils mettent des semaines en ce moment à livrer. Un ami en a commandé une le 17 avril. On attend toujours. Et bien sûr, impossible d'avoir une date approximative (c'est tellement trop dur de faire date aujourdhui + temps livraison pieces + nombre de serveur commandés * temps de preparation d'un serveur...)

si ça un rapport : je t'indique juste que le premier avantage que tu indiques dans ton commentaire précédent n'est pas valable puisque PDO le fait déjà.

Je n'ai pas dit par contre que PDO faisait ce que tu décris dans le deuxième avantage.

le fetch object de php renvoit 1 seul et unique object par tuple. Cette objet à ma connaissance n'embarque aucune méthode, et récupère en propriété tout les champs du tuple

Utilise PDO disponible dans php5 : tu peux indiquer la classe à utiliser pour l'instanciation des objets (donc indiquer tes propres classes).

pour le 1) : relis ton histoire de france (et la constitution qui n'est pas totalement claire sur le sujet quand même). Le président actuel n'est pas le premier à agir de la sorte. Et je dirais même que la majorité des présidents de la république ont suggérés à leurs premiers ministres de proposer tels ou tels ministre. Il y a juste que certains (chirac par ex) sont plus "discrets" que d'autres.

Bref, on a une présidence "forte", et ce n'est pas la première fois...

> C'était une question.

Désolé, mais je l'ai lu comme une supposition. Comme ta phrase ci dessous d'ailleurs : tu supposes qu'ils ne font rien à ce propos alors que c'est faux. En ce qui concerne les retours sur FF3, cela ne t'auras pas échappé qu'il n'en est encore qu'au stade alpha, et qu'il est alors bien imprudent d'annoncer quelconque malfaçon comme tu le fais ci-présent.

>Faire un break dans l'implémentation de nouvelles fonctionnalités pour se concentrer uniquement sur ces problèmes seraient une très bonne chose je pense.

Il y a pratiquement des personnes qui ne font que ça. Et franchement, je ne vois pas en quoi les deux types de développements (optimisations/newfeatures) serait incompatibles. De toute façon, il y a des corrections de bugs qui nécessitent des compétences spécifiques que n'ont que très peu de personnes. Alors pendant que les personnes concernées corrigent les bugs/leaks profonds, les autres devs (payés ou bénévoles) font quoi ? ils se tournent les pouces ?

devenir une usine à gaz ? non du moment que ce qu'il propose est réèllement utilisé et bien implémenté. C'est pas parce qu'il y a plein de fonctionnalités que c'est une usine à gaz.

Pour le suivi du rythme et en ce qui concerne Konqueror : trés honnetement, si apple n'avait pas pris khtml comme moteur, il ne serait pas là où il en est, même avec toute les bonnes volontés de l'équipe khtml. Les grandes avançées dans le moteur Khtml sont dues aux developpements qu'ont fait les devs d'apple, si je ne raconte pas de bêtises. Mais ce n'est pas forcément négatif. Apple fait parti du WHATWG, donc en principe implémentera toutes les nouvelles features liées au moteur dans webkit, que pourront alors reprendre les devs de khtml pour intégrer dans Konqueror. Je ne pense donc pas que les jours de Konqueror soient comptés.

Pour une meilleure intégration de Firefox dans KDE, faudrait que quelqu'un travaille sur l'intégration de qt comme toolkit dans Gecko. Il fut un temps où ça marchouillait, mais je crois que c'est un peu à l'abandon de ce coté là effectivement. http://lxr.mozilla.org/seamonkey/source/gfx/src/qt/
http://lxr.mozilla.org/seamonkey/source/widget/src/qt/ (et il faudrait travailler sur d'autres composants pour mieux communiquer avec KDE, genre le clipboard, le wallet etc)

>Je ne vois pas non plus comment ferait un primo-arrivant sur le marché du navigateur.

Si tu remarques bien, ce fait n'est pas nouveau. depuis combien d'années il n'y a pas eu de "grand" navigateur ? Ou plutôt de nouveau moteur de rendu web utilisé par un des principaux navigateurs ? pas loin de 10 ans ? (le dernier doit être khtml non ? et ça fait combien d'années qu'il a débuté ce projet ?)

ba demande aux developpeurs web 2.0 ce qu'ils en pensent de toutes ces nouveautés ;-) C'est pas tant une question d'urgence, qu'une question d'avancer. Il FAUT faire évoluer la plateforme web, si on ne veut pas que les applications web migrent vers des trucs proprio comme silverlight ou flash/apollo. Car il est clair que si la plateforme web ne répond pas aux besoins des développeurs, ils finiront par migrer vers d'autres technos, d'autres plateformes (vers toujours plus de facilité, de possibilité etc..)

Bref, finalement si, c'est une urgence.

Et en tant que simple utilisateur, tu as aussi à y gagner : des applis/sites mieux conçu, plus légèrs, offrant plus de possibilité etc...

C'est chiant ces complaintes à répétition à propos des leaks and co. Et c'est encore plus chiant de voir ces suppositions de fuites mémoires sur des choses que tu n'as même pas encore testé.

Les devs Mozilla y travaille dur sur ces problèmes, qui ne sont pas évident à résoudre vu la complexité du code. M'enfin dans Firefox 3, les choses devraient s'améliorer car de nombreuses améliorations ont été fait en ce sens, notamment l'intégration d'un cycle garbage collector &cie, la deCOMtamination de certains objets du coeur (ce ne sont plus des XPCOM, mais ça je dirais que ça améliore plus la performance que corriger des leaks ) etc..