> 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.
Option 3 is what I chose for my annotation engine - I use a registry, where I can configure which type implements what annotation, and also I can disable certain "useless" annotations, e.g. those that are just used for documentation generation. I don't know what's undesirable about that? Any application is going to have a finite number of annotation types - having the registry actually gives you additional flexibility and decouples the annotation-name from it's implementation. In my implementation, standard annotations come pre-configured, and known documentation-only annotations are ignored by default. If somebody doesn't like the standard annotation for @var, or wish to extend the class that implements it, they can do so. This approach is consistent - you don't have to worry about autoloaders, because the annotations are loaded the same way as any other class. No special circumstances - they're just classes. If your codebase uses an annotation that isn't defined in the registry, it will assume (not "attempt", but ASSUME) that the annotation is implemented in a single, default namespace, which can be configured for the annotation manager - if you use custom annotations in your application, you might make use of this feature. If the annotation does not exist, loading annotations for the offending file will fail, which is as it should be - you can't silently ignore missing annotations, anymore than you could safely ignore any other missing code in any piece of software. What a scary thought. Annotations are not just convenient metadata that may be useful if it happens to be available - annotations are code, and if used for more than documentation purposes, they are part of your software, and the possibility that any annotation might get ignored could lead to serious problems. For example, serious security problems could arise from silently ignoring an annotation that specifies password-validation on a form; allowing null-values for a property that was flagged as @required could lead to serious problems, including database inconsistencies and other problems that would be painful (potentially impossible) to recover from on a production system. Trivial mistakes, like forgetting to deploy an annotation class, could lead to serious problems - are you willing to sacrifice security and stability for "convenience"? -- 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
