Preumz 
Aller debout là dedans ! [:kramoc]
Deuz :hello:
Ce message n’était pas conforme aux règles d’utilisation du nouveau forum :
:hello:
:hello:
la pub cay le mal :o
Trop tard, j’ai oublié, c’était bieng?
CVS, cay bien may cay tray long !!! :sleep:
Surtout pour les gros fichiers, avec la confirmation de réception et tout le bazar, t’as le temps d’apprendre le japonais ! :o
Mais en gros ce que t’as dans classLoader::load() c’est une vérification d’existence de classe, une vérification d’existence de fichier de classe et un require() du fichier (ou pétage d’exception ) non ?
Question : faut-il mieux faire un chargeur de classe qui scanne un dossier à la recherche de fichiers PHP de classe (d’extension “.class.php” par exemple) ou bien alimenter un fichier de configuration de ce chargeur de classe où l’on déclare toutes les classes qu’il doit gérer ?
Je pense que pour les performances, la deuxième solution est meilleure, mais j’ai l’impression qu’elle est moins user-friendly. :neutre:
Je suis en train de mesurer les pours et les contres de __autoload() et j’en entends beaucoup de mal :-/
PS : N’est-ce pas plutôt : classLoader::getInstance()->load($class); ? 
Si (:: au lieu de ->)
Et __autoload() m’a permis de réduire de 50% le temps de chargement des classes de mon parser (un fichier par classe quand même).
Concrêtement, ce que je fais : j’ai une classe qui parse (ou scanne) tous les fichiers PHP pour chercher les classes, fonctions, et qui permet de les mapper par rapport à un chemin absolu relatif à un path (INCLUDES_GLOBAL . ‘/VersMaClasse.php’)
Et ensuite, je charge ce fichier (vu que j’ai une map[className] => file, et je laisse PHP faire son micmac
Scanner un dossier, ça peut être une bonne idée, encore faut-il avoir une bonne convention de nommage, et mettre tout à la racine (paf). De plus, ça permet pas de gérer le cas deux classes dans un fichier (où trouver la seconde classe si le nom du fichier dépend du nom de la première?)
Certes, reparser les classes c’est lourd, tout ça… mais le gain est là : require_once est plus couteuse que __autoload, car PHP est forcé de faire un realpath sur le fichier, de résoudre l’arborescence, ce qui n’est pas le cas d’autoload (basé sur le nom de classe).
Voilà.
OK, c’est grossièrement ce que j’ai implémenté également (convention de nommage : “packagePere__packageFils1__packageFils2__…__NomClasse.class.php”) avec deux collections :
- $registeredClasses (celles trouvées lors du scan du dossiers des classes)
- $loadedClasses (celles précedement chargées par des appels à loadClasse($name) ou loadPackage($package)Le seul truc que je n’ai pas fait c’est INCLUDES_GLOBAL, mais je n’ai que récemment appris qu’il était possible d’optimiser le temps d’inclusion d’un fichier (je pensais qu’un include(‘script.php’); depuis le script index.php regardait directement et uniquement dans le dossier contenant le fichier ayant demandé l’inclusion (index.php)).
include oui, sûrement. include_once non. Sinon tu ne peux assurer que le fichier n’a pas déjà été lu : la seule chose principale (clef primaire!) qui différencie un fichie d’un autre, c’est son chemin absolu.
Moi j’utilise pas de convention genre packagePere__…__class
Faut pas exagérer, ensuite ça fait des noms à rallonge. 'fin bon, mon script cherche juste des déf. de classes.
(j’attends de php6 une gestion des namespace ou des packages d’ailleurs).
Un drakkar normand, ça intéresse quelqu’un ? :MDR
> Sans-Nom
Pour les namespace, ça peut être pas mal oui, il y a d’ailleurs des projets en ce sens (et même une pétition, que je ne trouve plus…)
Par contre pour l’autoload… autant c’est plus rapide que des {include|require}_once(), autant ça fait pas le poids face à un vrai include. Si tu veux gagner du temps, je le répète : fais tes include à la main.
PS : je suis promu rédacteur sur PHPTeam 
Au contraire je gagne du temps - d’éxécution - et du temps de programmation : j’ai plus à me soucier de savoir si c’est là ou non, ça le fera tout seul en me levant une exception si rien n’a été trouvé
Pire que ça : si je veux changer une classe à la volée (debug, testing, etc) je peux le faire facilement : suffit de changer une ligne dans un SEUL fichier, et rien d’autres
Mon parser de fichier PHP n’a plus qu’à être exécuté via un make des familles, ou un .sh, .bat, etc T’imagines pas le gain que ça m’a apporté.
(et aussi, ça m’a permis de bypasser des problèmes d’incursions récursives (en gros A implémente B, dont une méthode prend un paramètre de type A…)).
Le temps de développement je veux bien te croire, ça sert à ça ! 
Mais pour le temps d’exécution, crois-moi, c’est beaucoup plus lent qu’un include classique. Je fais des audits sur ça en ce moment… fais un test avec XDebug et WinCacheGrind par exemple, tu verras, c’est flagrant !
Moi j’avais un tas de require_once partout : depuis que je les ai viré, j’ai gagné 100 ms.
De toute façon, je trouve ça un peu dépassé qu’il n’y ait pas un système de ClassLoader comme en Java. Autant en C, C++, etc, c’est tout à fait normal vu que c’est compilé, c’est pas très grave car au final c’est un binaire et y a plus de dépendances avec les fichiers.
Mais en PHP, ou autre, c’est lourd plus qu’autre chose.
J’aimerai bien voir tes tests pour voir
Moi je peux rien te donner, car le code a trop évolué pour que ça prouve mes dires (j’ai juste constaté). Ceci étant, vu que j’utilise à 100% les objets, une classe par fichier (ou à peu près, le cas des classes enfantes est à part), je me vois mal revenir à require_once sauf pour des trucs logiques.
Pour tes deux logiciels, pour WinCacheGrind, je suis tombé sur ça sur le blog :
http://www.hendyirawan.web.id/2007/02/08/raelians-are-fun/
;D
Mouarf, je vais aller pêcher avec ça :MDR
C’est où le lien pour écouter ?
www.stunradio.com, tu regardes en haut a gauche, en fonction de ton lecteur multimédia
Et quand on a aucun de ceux-là ?
je déconne :o
InSiderZ>Ok on y est à dans 5 minutes
C’est l’heure