That RFC is not from core developers, its from Doctrine's guilhermeblanco, so its coming "from our end" of the php world.
On Thu, 26 May 2011 10:55:49 -0700 (PDT) stloyd <[email protected]> wrote: > 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 > -- 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
