@Benjamin Maybe I used bad words, but I meant that non of core developer (AFAIK) rejected that RFC. But point is we should be as far as we can compatible with it.
On 26 Maj, 20:11, Benjamin Eberlei <[email protected]> wrote: > 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
