The problem with replicating the spl_autoload* fns as doctrine_annotation_autoload* is the global state.
Since parsing annotations is always sort of cached you can easily run into problems here or need to throw an exception of the sort "changing autoloading is prevented, a reader has already accessed this data, we have to prevent caching issues". greetings, Benjamin On Fri, 1 Jul 2011 17:43:47 -0700 Kris Wallsmith <kris.wallsm...@gmail.com> 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 <kont...@beberlei.de> 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 <kont...@beberlei.de> 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 symfony-devs@googlegroups.com > >> To unsubscribe from this group, send email to > >> symfony-devs+unsubscr...@googlegroups.com > >> 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 symfony-devs@googlegroups.com > > To unsubscribe from this group, send email to > > symfony-devs+unsubscr...@googlegroups.com > > 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 symfony-devs@googlegroups.com > To unsubscribe from this group, send email to > symfony-devs+unsubscr...@googlegroups.com > 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 symfony-devs@googlegroups.com To unsubscribe from this group, send email to symfony-devs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
