We had the requirement on silent auto-loaders since the beginning (this was not added recently), and there was not a single report where this was a problem (or at least I'm not aware of it). The file_exists check that silent auto-loaders are doing in development can be dropped in production for example by using the ApcUniversalClassLoader. So, there is no performance penalty.
I have to ask again, what problem are you trying to fix? Johannes On Sat, Jul 2, 2011 at 2:43 AM, Kris Wallsmith <[email protected]>wrote: > This binds the reader to PSR-0, right? I'm not sure you want to do > that. Why not just expose a method to register autoload callables, > similar to the spl_ function? Then you can register a special loader > or just register spl_autoload_call. > > k > > On Jul 1, 2011, at 3:16 PM, Benjamin Eberlei <[email protected]> wrote: > > > Hello, > > > > implementing an autoloading mechanism just for annotations is really > simple: > > > > https://github.com/doctrine/common/compare/master...Autoloading > > > > The problem is how we design extension points. > > > > Just stuffing the universal loader namespaces map into the annotation > reader as shown here looks convenient, but it isnt. > > See code: https://gist.github.com/1059486 > > > > 1. The universal loader is not necessarily a production loader, so using > this data is not a good idea. > > 2. The loader looses scope very fast, there is no real way to get it > back. > > > > This sort of leaves us with registering annotation namespaces explicitly > at some other location, which is rather unconvenient and probably complex to > do. > > > > Other options would either be: > > > > 1. Go back to a 2.0.x approach, every component uses its own reader and > no validation is performed. > > 2. Requiring all annotation classes to be require_once'd before using > them as annotations. > > 3. Adding a global static dependency that knows about all the > annotations. > > > > All these are not really desirable. > > > > At that point it might even be better to just keep the current way and > just life with the downsides, i.e. requiring silent autoloaders. > > > > On Fri, 01 Jul 2011 10:34:14 +0200 > > Benjamin Eberlei <[email protected]> wrote: > > > >> Yes, registering all namespaces. This is how it works at the moment > >> anyways, since the annotation reader with autoload = true is backed up > >> by php autoloading. > >> > >> The benefits are that its easy to migrate to and it is essentially a > >> no-additional-configuration solution, allowing users to add new > >> validation constraints for example without having to bother about > >> autoloading the annotations at all. > >> > >> On Fri, 01 Jul 2011 10:28:38 +0200, Christophe COEVOET wrote: > >>> Le 01/07/2011 10:23, Benjamin Eberlei a écrit : > >>>> On Fri, 01 Jul 2011 10:17:17 +0200, Christophe COEVOET wrote: > >>>>> Le 01/07/2011 10:12, Benjamin Eberlei a écrit : > >>>>>> Yes, I know this is a problem, but even in the case currently all > >>>>>> the annotation classes have to be made available (through an > >>>>>> autoloader). Registering all possible annotations either with their > >>>>>> class name in a hashmap or already calling require_once on them is > >>>>>> just another mechanism that is not as convenient but allows more > >>>>>> robust docblock parsing. Also the "hack" to doctrine annotations > >>>>>> loading is only necessary, because these classes are organized in a > >>>>>> non psr-0 structure. So these classes are pre-loaded in a hackish > >>>>>> way, because there is no other mechanism for the autoload = true > >>>>>> case. > >>>>>> > >>>>>> We already set annotations: true for validators and registering > >>>>>> the ExtraBundles is also a statement "pro annotation", so we do have > >>>>>> simple ways in Symfony2 to collect the class-names of all possible > >>>>>> annotations. I propose to change the following on AnnotationReader: > >>>>>> > >>>>>> 1. Add a method to register annotation classes: > >>>>>> > $reader->registerAnnotation("Symfony\Bridge\Doctrine\Validator\UniqueEntity"); > >>>>>> and $reader->registerAnnotations(array(..)); > >>>>>> 2. Add a method to register files that contain annotations: > >>>>>> $reader->registerAnnotationFile(".."), directly loading them via > >>>>>> require_once; > >>>>>> 3. Add a method to register annotation namespaces: > >>>>>> > $reader->registerAnnotationNamespace("Symfony\Component\Validator\Constraint", > >>>>>> $dir). This is used to create a silently failing PSR-0 "autoloader" > >>>>>> for this path + directories. It can be automatically populated from > >>>>>> data in the UniversalClassLoader. > >>>>>> 4. Change the class_exists check to never use autoload = true. If > >>>>>> a class is part of a registered annotation namespace (only directly > >>>>>> in the exact namespace, no subnamspacing), try load the file based > >>>>>> on a silent PSR-0 autoload for it using an autoloader impl. > >>>>>> contained in the AnnotationReader (not the php autoloading > >>>>>> mechanism), before triggering the class_exists($name, false) > >>>>>> > >>>>>> This way for symfony only the UniversalClassLoader data has to be > >>>>>> used to populate the registered annotation namespaces. > >>>>> This seems good. And in Symfony, we can implement it by adding a > >>>>> tag > >>>>> on services in which the annotation reader is injected giving the > >>>>> needed data to register the annotations in the annotation_reader > >>>>> service. This will require a bit work for people writing an > >>>>> annotation > >>>>> driver but they still have to work. > >>>>> This should probably be done before the Symfony2 release to avoid > >>>>> BC > >>>>> issues after that. > >>>> > >>>> A tag is not necessary, the data from the universal class loader > >>>> would suffice to register the new autoloader inside the annotation > >>>> reader. Doctrine Bundle (and third party ones in need of special > >>>> integration) could use a compiler pass to add the > >>>> $reader->registerAnnotationFile() call. This would cover 99,9% of all > >>>> use-cases. > >>>> > >>> But registering which namespaces ? You would register all namespaces > >>> of the autoloader instead of just the one containing annotations ? > >>> > >>> -- > >>> Christophe | Stof > >> > >> -- > >> If you want to report a vulnerability issue on symfony, please send it > to security at symfony-project.com > >> > >> You received this message because you are subscribed to the Google > >> Groups "symfony developers" group. > >> To post to this group, send email to [email protected] > >> To unsubscribe from this group, send email to > >> [email protected] > >> For more options, visit this group at > >> http://groups.google.com/group/symfony-devs?hl=en > >> > > > > -- > > If you want to report a vulnerability issue on symfony, please send it to > security at symfony-project.com > > > > You received this message because you are subscribed to the Google > > Groups "symfony developers" group. > > To post to this group, send email to [email protected] > > To unsubscribe from this group, send email to > > [email protected] > > For more options, visit this group at > > http://groups.google.com/group/symfony-devs?hl=en > > -- > If you want to report a vulnerability issue on symfony, please send it to > security at symfony-project.com > > You received this message because you are subscribed to the Google > Groups "symfony developers" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/symfony-devs?hl=en > -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
