On 11/25/15 10:31 AM, Pedro Cordeiro wrote:
2015-11-25 13:47 GMT-02:00 Lester Caine <les...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
