I think refactoring is an good idea, but... As core developers are considering putting annotations parsing into PHP [1] we should try to fully support this an use as default one (also maybe we then find out some improvement for that RFC [1]).
I'm not against, but I believe that be compatible with RFC [1] and using it as default one, make future changes more simple and more user friendly. [1] https://wiki.php.net/rfc/annotations-in-docblock On 26 Maj, 18:39, Jordi Boggiano <[email protected]> wrote: > 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
