Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89411
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.26 cause and error)
To: internals@lists.php.net
References: <CAJGzsHriGp9PoYq++=CBQptFYZQiAsa+yxxN076BHxMQGD6HrA@mail.gmail.com>
 <5654B516.4020700@gmail.com>
 <CAESVnVpe3+9=N5rkcHp2O5cdGuFnt_EQ=sSV8ucpv5w=ox-NaA@mail.gmail.com>
 <CAJGzsHoP5mc2_demfWM3r7exN4qLThANcbcwo9SBydGpvmB1WQ@mail.gmail.com>
 <5655D82A.8020304@lsces.co.uk>
 <CAJGzsHr3XfxRGA8DSkLzAf-8AQvJPu1GMVE30PX=ScygMPgCPQ@mail.gmail.com>
Message-ID: <5655E4E4.8070200@garfieldtech.com>
Date: Wed, 25 Nov 2015 10:42:12 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0)
 Gecko/20100101 Thunderbird/38.0.1
MIME-Version: 1.0
In-Reply-To: <CAJGzsHr3XfxRGA8DSkLzAf-8AQvJPu1GMVE30PX=ScygMPgCPQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Native Annotation Syntax
From: larry@garfieldtech.com (Larry Garfield)

On 11/25/15 10:31 AM, Pedro Cordeiro wrote:
> 2015-11-25 13:47 GMT-02:00 Lester Caine <lester@lsces.co.uk>:
>
>> Any new system would require
>> every third party tool to be adapted to use it
>>
> That's not true at all. A new syntax would in no way invalidate parsing
> annotations from docblocks.
>
> The only legacy code that is supported by IDEs (if they are, PHPStorm will
> not hint/autocomplete, nor will eclipse/netbeans) would be
> Symfony2/Doctrine2. There are tons of other tools that with custom
> annotations (JMSSerializer as an example) that do not have any support at
> all.
>
> This argument is so flawed that you didn't consider that there are many
> parsers with many different syntaxes (
> https://github.com/jan-swiecki/php-simple-annotations,
> https://github.com/nette/neon) and that ANY implementation, be it through
> docblocks or with a native syntax would require a rewrite anyway for many
> projects if those tools want to support the new native feature.
>
> Also, doing it through an extension is a nice way to delay adoption,
> because shared hosts rarely give the option to install new extensions.
>
> I don't have a vote here, but if I had, I'd strongly oppose any
> docblock-based implementation.

When Drupal adopted annotations, the absolute #1 objection people had 
was "but docblocks aren't code, you moron!"  There's no value in 
language-native annotations being in the docblock, other than BC with 
*some* existing implementations.  However, doing so would make static 
checking more difficult; If annotations become a language-native 
feature, they should be a first-class citizen to make it easier for IDEs 
to handle.

I'm also not super picky on what the tokens are, however I do think 
mapping them to actual classes, like Doctrine does, would be the most 
flexible.  Structured data all the things.  That also means annotations 
can be namespaced, be affected by use statements, and so forth.  In a 
sense, they become isomorphic to:

class Foo {
   public static function getAnnotations() {
     return [
       new OneToMany('a', 'b', 'c'),
       new Stuff('d', 4);
     ];
   }
}

Except they can be applied to anything reflectable rather than just 
classes.  (Functions, methods, classes, object properties.)

Sara's suggestion of making them legal within a // comment line for BC 
reasons is interesting, but we don't do that for any other new syntax 
AFAIK.  Plus, it means it's harder to comment out an annotation 
temporarily for debugging.  There's still /* */, but it's one more quirk 
to have to think about.

-- 
--Larry Garfield