Discussion :

[_skip]

Bonjour,

Je n'arrive pas à trouver une vraie réponse à ce problème. Je mets actuellement à disposition une librairie permettant de faciliter l'utilisation de services distants (payants) développés par mon entreprise. La version actuelle comprend une quarantaine de classes, pour faciliter au maximum la mise en oeuvre, il y a un seul répertoire et l'inclusion est gérée par des require_once().
Ca fonctionne, personne ne s'est jamais plaint, mais niveau maintenance ça commence à devenir pas terrible de gérer tous les cas d'utilisation de la lib sans tout à coup oublier un require_once() quelque part, et ce d'autant plus que ce n'est pas facilement détectable.

Donc j'hésite à utiliser un autoloader, mais je sais pas si c'est une pratique acceptable dans le cas d'une librairie tierce. Est-ce que je peux raisonnablement demander à mes utilisateurs d'enregistrer mon propre autoloader dans leur stack? Il me semble que que ça pourrait être vu comme une exigence assez intrusive.

Je n'arrive pas à trouver vraiment un état de l'art en la matière. J'ai regardé pas mal de librairies sur le net, la moitié du temps soit elles sont super simples et utilisent include/require, soit elles sont conçues spécifiquement pour des frameworks et elles utilisent les conventions de ces derniers.
Un petit conseil ou une piste pour moi? Est-ce que vous jugez raisonnable qu'un code tiers exige d'enregistrer son autoloader ou au contraire vous trouvez que c'est pas concevable à cause... par exemple de conflits ou de soucis d'indépendance du projet par rapport à la lib en question?

[grunk]

L'idéal est à mon avis un autoloader qui respecte le standard PSR-0
Si en plus tu veux simplifier la vie de tes utilisateurs tu peux carrément en faire un package composer (voir cette doc en particulier) ce qui permettra des installations ultra rapide.

[Tsilefy]

Autoloader sans hésiter.
S'ils utilisent composer, il n'y aura aucun problème. Sinon, tu peux mettre ton autoloader dans un fichier bootstrap et leur demander d'inclure ce fichier.

[_skip]

Merci pour vos réponses.
Donc pour vous c'est pas un problème d'amener son propre autoloader pour une librairie tierce. Effectivement j'aurai certainement fait ça en demandant d'inclure un fichier qui aurait fait le "register".
Je suis déjà tombé sur PSR-0 lors de mes recherches, par contre j'ai aussi cru comprendre que c'était basé sur les namespaces qui sont devenus accessibles en 5.3. J'hésite à dropper le support pour 5.2 dans ma prochaine version mais je ne sais pas encore si je vais le faire car je trouve peu d'infos sur les parts de marché de 5.2.

[grunk]

5.2 est sortie en 2006 autant dire qu'un serveur encore sous cette version c'est une faute professionnel.

Pour des stats de version tu peux regardé sur le blog de pascal martin :
http://blog.pascal-martin.fr/post/st...ns-php-2013-11

[_skip]

Je suis d'accord avec toi pour 5.2, mais si tu voyais les trucs sur lesquels je tombe parfois, enfin je pense que tu imagines sans peine... Faut que je réfléchisse à tout ça.
En tout cas merci pour les conseils et tous les pointeurs, ça m'a été très utile.

Si vous voulez ajouté quelque chose, hésitez pas.

[grunk]

Une solution qui peut être intéressante c'est de ne pas casser la rétro compatibilité de l'API (donc par exemple la v1 et la v2 font les même appel) mais de ne proposer que les nouveautés dans la v2.
En terme de développement ca t'impose de maintenir 2 branches de code pendant un certains temps , pour que tes "mauvais" clients soit pas mis au pied du mur.

Je ferais un truc du genre :
v1 : correctif de sécurité uniquement , jusqu'au xx/xx/2014 puis abandon complet (support compris). Une fourchette de 6 mois à un an me semble correcte.
v2 : correctif de sécurité, nouvelle fonctionnalité, et tout les truc habituels.

Avec un SCM comme subversion ou git , c'est finalement assez simple à gérer.

[_skip]

On va sûrement faire un truc dans ce genre, car non seulement il y aura une mise à jour de la librairie client mais aussi du serveur. Et je veux éviter d'avoir à adapter l'ancienne lib pour qu'elle fonctionne avec le nouveau serveur, on a changé trop de choses et ça donnerait un compromis trop dégueulasse entre l'ancienne API et les fonctionnalités réelles. Va falloir qu'on annonce ça car on s'est jamais doté d'une politique EOL vraiment claire vis à vis de nos clients.