PEAR contre PECL

Le mercredi 3 août 2005 à 14:53, commentaire par LaurentJ :: site :: #

L'avantage d'un module C : les perfs, et la possibilité de lié php avec le reste du monde.

Mais :
- ça demande beaucoup plus de rigueur car il y a des risques de crash si on code avec ses pieds (ce qui, en php, n'est pas grave pour le système, tout au plus, l'appli bug, mais fait pas planter le serveur). PECL n'est donc pas à la portée immédiate des développeurs PHP en général je pense (qui pour beaucoup, ont commencé à coder avec PHP et n'ont donc aucune notion de pointeur, de gestion mémoire etc..)
- pouvoir utiliser les modules PECL, nécessite un accés à la configuration du serveur. Or le succés de PHP s'est fait grâce aux hebergeurs : les developpeurs web n'ont en général aucun contrôle sur le serveur. D'où moins d'interet pour PECL (qui ne leur sert à rien), donc moins de "vocation" à faire du PECL :-)

C'est en tout cas ma vision de la chose.

Conçernant groupe de pilotage, QA &co, ça a toujours été un manque à mon avis. Il n'y a pas beaucoup de cohérence entre les api des modules (même si ça a tendance à s'améliorer). J'ai l'impression que pour PEAR ou PECL, les developpeurs font leur truc dans leur coin, sans demander l'avis des autres. Ce qui donne ce "bordel" ambiant dans les API, et des doublons (y a bien 3 moteurs de templates dans PEAR il me semble..). Cette impression de bordel est aggravée par la doc : quand est ce qu'ils vont faire une doc avec les modules classés par catégories !!! leur classement alphabétique ne rime strictement à rien !

Le mercredi 3 août 2005 à 18:24, commentaire par perrick :: site :: #

LaurentJ > Je suis bien conscient des avantages d'un module en C. Et surtout de la difficulté de son développement. C'est même le point de départ de ma question : pourquoi cet écart entre les marches d'entrée ne se retrouve-t-il pas dans le nombre de paquets ?

C'est marrant que tu trouves qu'il y a 'trop de bordel' : moi j'ai l'impression qu'il n'y en a pas assez ;-) Tout est bien ordonné : pas facile d'y trouver de la "vie".

La question des doublons est encore pire : il y en a peu. Et quand ils existent, il y a peu de moyen de savoir lequel est meilleur par rapport à l'autre (par exemple : taux d'activité -- SourceForge / vote des utilisateurs / étoiles de la QA team, que sais-je encore).

Le jeudi 4 août 2005 à 07:36, commentaire par Arnaud :: #

Il y a les stats de téléchargement par paquet sur chaque "homepage" d'un paquet.

ex:
pear.php.net/package-stat...

Les étoiles de la QA team est une idée qui à été évoquée mais nous ne sommes pas allé plus loin pour le moment.

Le jeudi 4 août 2005 à 14:00, commentaire par Moosh :: site :: #

PECL existait virtuellement avant PEAR.

En effet, il n'y avait pas de pear que des développeurs de tout coté faisait le module C dont ils avaient besoin et qui manquait à php.
C'est modules étaient ajouté à php ou proposé sur le coté.

PECL apparu a rassemblé ces modules et le php distribué a commencé à être élagué releguant à PECL tout ce qui est un peu "particulier"

PEAR lui c'est parti de Zero, avec une communauté plus vive
Le programmeur PECL qui est encore plus isolé que le programmeur PEAR.

Pourtant qui utilise les packages ?

PEAR est accessible aux développeurs alors que PECL necessite un accès plus grand au système.

Coté normalisation, la normalisation du code dans PECL est "dans les tripes" c'est celle de C.

Dans PEAR c'est en PHP, avec toutes les manières qu'il existe de coder en php et d'arriver à un résultat fonctionnel aboutir à une méthode uniformisée demande bcp d'effort sur les codeurs de classes qui préfèreront être indépendant et aller enfouir leur classe dans le foutoir de phpclasses.
Le seuil d'entrée à PEAR est plus important que de rester dans son coin.
il faut écrire un code sur les coding rules de PEAR,
utilisee l'existant (donc le connaître), être responsable et pas dictateur de son package, écrire une doc, écrire des tests, ...


Autre constatations : PEAR est mal aimé des français (des francophones ?)

Le jeudi 4 août 2005 à 14:07, commentaire par Moosh :: #

Je réponds à Laurent :

"Conçernant groupe de pilotage, QA &co, ça a toujours été un manque à mon avis. Il n'y a pas beaucoup de cohérence entre les api des modules (même si ça a tendance à s'améliorer). "
En fait si il y a une QA, mais qui est arrivée très tard et il y a un boulot monstre...
En outre , c'est à croire qu'il n'y a que cette QA qui y bosse, les utilisateurs préfèreront cracher puvbliquement sur un package et chercher une solution locale au problème rencontré plustot que de remonter le problème , oser proposer des solutions, en discuter...

"J'ai l'impression que pour PEAR ou PECL, les developpeurs font leur truc dans leur coin, sans demander l'avis des autres. Ce qui donne ce "bordel" ambiant dans les API, et des doublons (y a bien 3 moteurs de templates dans PEAR il me semble..)."

Comme je disait dans mon premier commentaire, les devs sont plus isolé ou dans un clan plus isolé

Coté PEAR, ca progresse, mais ca touche cette P*tain de fierté des programmeurs, les gens n'aiment pas qu'on pointe leurs erreurs, les packages qui progressent le mieux sont ceux où les mainteneurs ne te remballent pas quand tu fais une remarque (bonne ou erronée) mais t'expliquent ou t'écoutent.

Le jeudi 4 août 2005 à 14:11, commentaire par Moosh :: site :: #

"La question des doublons est encore pire : il y en a peu."

Ca ne devrait pas aller en s'améliorant, une des piste d'acceptation des packages est "un seul packages par features"

l'idée derrière ca c'est de préferrer une fusion d'idée de 2 programmeurs dans un package qui s'enrichi des 2 têtes plutot que 2 packages avec du bon et du mauvais.



A votre avis combien de réponses ai-je eux à cette publication dans mon blog ?
moosh.et.son.brol.be/dotc...
...

0, nul, zero, nada, nothing, niente, rien, niks.

Le jeudi 4 août 2005 à 15:30, commentaire par perrick :: site :: #

En 1995 il y avait un moteur principal : altavista.digital.com, c'est tout. Petit à petit : un autre est arrivé Google. Et tout le monde a changé ou presque. Sauf que personne n'a osé dire : il y en a déjà un, pas la peine d'en faire un deuxième.

Idem pour les distributions Linux : Ubuntu -- la dernière en date -- est finalement celle que j'utilise régulièrement.

Tout ça pour dire que le 2ème développeur avec un package "concurrent" il développe sa partie en prenant le contre-pied du concurrent. Son paquet est intéressant **parce que** ce petit bout est à l'opposé du paquet initial et parce qu'on pourra en discuter jusqu'au bout de la nuit.

Le jeudi 4 août 2005 à 16:17, commentaire par Arnaud :: #

Perrick: la question des doublons soulèvent les passions. Comme Moosh le dit l'idée est qu'un paquet existant soit modifié pour incorporer les nouvelles idées.

Si cela n'est pas possible le nouveau paquet peut très bien être accepté car très différent.

Honnetement avoir deux paquets qui font la même chose alors que leurs différences internes sont légères et peuvent être fusionnées ne sert pas à grand chose. Le cas d'une approche différente à un problème devient intéressante.

Le vendredi 5 août 2005 à 01:15, commentaire par Moosh :: #

oui je ne dit pas le contraire, je crois que les deux ont des inconvénient et des atouts.

Pour moi il est normal d'avoir plusieurs systèmes de template mais il serait absurde d'avoir deux méthodes pour extraire les idTags d'un mp3.

Le vendredi 5 août 2005 à 10:24, commentaire par perrick :: site :: #

Avoir deux paquets qui font presque la meme chose sert a mettre l'un en valeur par rapport a l'autre ; parce qu'il est mieux code, parce qu'il est plus facile a integrer avec d'autres paquets PEAR, parce que ses bugs sont corriges rapidement.
De ce que j'entends, beaucoup de monde a l'air de dire qu'ils pouraient faire quelque chose de mieux pour tel ou tel paquet ! C'est qu'il y a un probleme qq part...

Le vendredi 5 août 2005 à 14:11, commentaire par Moosh :: #

"De ce que j'entends, beaucoup de monde a l'air de dire qu'ils pouraient faire quelque chose de mieux pour tel ou tel paquet ! C'est qu'il y a un probleme qq part..."

Oui c'est pour ca que je parlais sur le on -coup-de-gueule- de la fierté des programmeurs ...
BCP disent qu'ils feraient mieux mais veulent un nouveau package pour faire mieux au lieu de rentrer en contact chercher à améliorer l'existant, et ne faire un nouveau package que si c'est réellement plus que de l'amélioration.

En fait il y a plusieurs template ouais mais si on creuse ce ne sont pas les mêmes objectifs et contraintes qui sont prises en compte.

Donc la dualité pourrait se justifier mais (même si je ne les ai jamais regardée) je suis sur que les api ne sont pas uniformisées, que les sections communes sont développées sans communautarisation, ...
il y a aussi le problème des dépendances (argumet aupposé au précédent)

je dev un truc j'ai besoin d'une fonctionnalité qui existe dans un autre package.
Est-ce que je la copie ou j'inclu tout l'autre package juste pour cette fonctionnalité?

Le vendredi 26 août 2005 à 16:55, commentaire par pascaltje :: #

je me mets tout doucement à pear, pour les formulaires et l'interaction en DB.

ce que je n'aime pas?
- ne pas trouver la doc en français:
il y a surement un effort de traduction à faire de ma part, mais je dois d'abord connaitre les packages...
- la dépendance générale des paquets entre eux:
ça fait parfois 3-4 paquets à installer pour une classe utilisée en frontal
- pas d'outil visuel: je détaille

Le manque d'outil visuel est flagrant pour moi. réutiliser des classes, c'est un bon gain de temps, une fois l'apprentissage passé; par contre, toujours retaper le même type de code (config + appel de méthode) m'ennuie au plus haut point et est une perte de temps.

si j'ai utilisé un moment le template PHPLib, c'est parce que j'avais fabriqué un outil qui me machait le code de parsing; si je continue sur pear, ce sera probablement avec une sorte de "visual pear" qui dégrossit le boulot répétitif et inintéressant.