I know that we had that requirement. But people were only testing common in the context of Symfony with the UniversalClassLoader being silent.
I got two reports in the last days where users upgrading to Doctrine 2.1 had failing code due to the non-silent autoloader requirement. Part of the blame is on Gedmos library being written to much for Symfony and not handling the case where people use other class-loaders. Essentially both issues boiled down to the magic __NAMESPACE__ + $name being triggered on entities, for example MyProject\Entities\var, because of a @var annotation in a class and MyProject\Entities using the Doctrine or Zend Class Loaders for example. Removing __NAMESPACE__ is already a big step to make it much easier for a developer to control which namespaces have to be handled by silent autoloaders. greetings, Benjamin On Sat, 2 Jul 2011 07:58:14 +0200 Johannes Schmitt <schmitt...@gmail.com> wrote: > 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 > <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 -- 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
