thats why we implemented 3. Its undesirable because it uses a global static dependency, but there is just no other way.
On Sun, 3 Jul 2011 14:01:52 -0700 (PDT) mindplay <[email protected]> wrote: > > 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 > -- 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
