On 26.05.2011 17:58, Oleg Stepura wrote: > Do we really need to mimic the PHP syntax in annotations? As for me I > don't like the idea of having to print quotes for key names and arrows > just for that. Also to migrate to a new engine from old doctrine > parser I just had to do search-replace the @orm: with @ORM\ - now it > leads to more work to be done for migrating.
I would say that yes, we need to mimic PHP syntax. I feel your pain about the BC stuff, I got lots of code to update too, but BC is just a selfish argument at this point. We are not stable yet, we all knew what we did when we decided to start coding already. To me the value of having php syntax is great for newcomers, they can just anything they are used to type in there. If PHP core gets the short notation with [] for arrays, then we could support that too, it'd make things a bit shorter. > Is it case sensitive? @var loads the Annotation\Var - does that mean > that it's not? Good point. We need to be able to load all those old annotations, so I guess we could normalize everything with ucfirst(). People not respecting this convention for class names should suffer anyway. > What about adding custom Annotation namespace for current library > usage (DI config stage)? For example somebody already uses a class > that has some strange annotations (@test for example) and I extend > that class with the one which is parsed by annotation reader. It could > be that the class with strange annotations is from some vendor and I > cannot modify it to add written-by-me empty classes (why doing that?) > namespace for that strange annotations. The only good solution is to > teach the annotation parser to use more then \Annotation namespace to > search for classes before throwing an Exception. Or maybe to exclude > inherited classes from some namespace? Both ways to have maximum > flexibility? "There would be a set of standardized "autoimported" annotations" This means that yes, you could add your own global importer that marks test as skipped, or maybe configure the existing ignore importer. I'm not sure about internals at this point, but it sounds definitely possible to me. Cheers -- Jordi Boggiano @seldaek - http://nelm.io/jordi -- 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
