On Tue, Nov 24, 2015 at 11:05 AM, Rowan Collins <rowan.coll...@gmail.com> wrote:
> At first sight, these seem like details which could be tweaked later, but
> they make a difference to what syntax to standardise: is the annotation name
> just a string, or a valid class name? is the value of the annotation just a
> string, or a parseable PHP expression? is it more useful to use the de facto
> existing syntax in DocBlocks, or to add a new keyword or operator? etc
>
If we're going to use something in the docblock, then I wouldn't want
it parsed on compilation, but rather have it be an on-demand parse
while reflecting. The reason being that there are plenty of
docblock'd PHP libraries out there using invalid annotations because
they're not running it through tools to tell them what they got wrong.
Waiting till they've actually tried to examine it through reflection
lets us throw an exception on code that cares about it rather than
preventing code which ignores reflection from running.
I, for one, am a fan of Java style annotations which allow a string
name plus optional metadata.
@@foo
class Bar {
@@Baz("something", 123, [ 'a', 'b', ''c'])
public function qux() { ... }
}
Though the formality of having to define the annotation as an
interface is a bit overkill for PHP, the same rules Hack uses would be
clear and simple enough:
<<foo>>
class Bar {
<<Baz("something", 123, [ 'a', 'b', 'c'])>>
public function qux() { ... }
}
And no, I'm not picky about the parser symbol used... In fact,
allowing an optional '//' prefix to annotations might be nice for
compatibility.
-Sara
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
