Re: Annotation PHP 7

From: Date: Tue, 04 Nov 2014 22:42:56 +0000
Subject: Re: Annotation PHP 7
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17  Groups: php.internals 
Request: Send a blank email to internals+get-78689@lists.php.net to get a copy of this message
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 <ajf@ajf.me> wrote: > > > On 4 Nov 2014, at 21:31, Stas Malyshev <smalyshev@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: guilhermeblanco@hotmail.com GTalk: guilhermeblanco Toronto - ON/Canada

« previous php.internals (#78689) next »