Hi, By dealing with annotations in docblocks will force the Annotations parser to *much* smarter than you imagine.
Currently in Doctrine Annotations implementation, @param and @Param are considered different not only by first character to be uppercased, but rather because a class also exist in that namespace and also because it's an @Annotation. Smarter I mean that you'll have to build a rejection list of non-standardized annotations, such as phpdoc and phpunit. It also makes pretty hard to parse emails. You can see the list of ignored names as part of https://github.com/doctrine/annotations/blob/master/lib/Doctrine/Common/Annotations/AnnotationReader.php#L48 Regards, On Tue, Nov 4, 2014 at 5:20 PM, Andrea Faulds <a...@ajf.me> wrote: > > > On 4 Nov 2014, at 21:31, Stas Malyshev <smalys...@sugarcrm.com> wrote: > > > >> This brings the next piece of the puzzle. We have to update lexical and > >> semantical understanding of PHP. Taking Java's approach (@) does not > >> work in PHP, because it conflicts with error supression. Same thing > > > > Except for the mental context, how @ conflicts with errors? Suppression > > is always in runtime context and applied to expressions, annotations are > > always outside of it and apply to declarations. Unless of course you > > want to annotate variables and closures, but I'm not sure annotating > > expressions is such a good idea anyway > > At the top-level, @ is a shift/reduce conflict due to ambiguity between > statement annotation and expression. > > Though it might be possible to work around that with the AST (ew). > > -- > Andrea Faulds > http://ajf.me/ > > > > > -- Guilherme Blanco MSN: guilhermebla...@hotmail.com GTalk: guilhermeblanco Toronto - ON/Canada
