Re: Native Annotation Syntax
| From: | Rowan Collins | Date: | Wed, 25 Nov 2015 22:03:43 +0000 |
| Subject: | Re: Native Annotation Syntax | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-89433@lists.php.net to get a copy of this message | ||
On 25 November 2015 19:02:37 GMT, "guilhermeblanco@gmail.com"
<guilhermeblanco@gmail.com> wrote:
>Hi Rowan,
>
>If you're in a shared hosting, you can't "simply" remove the
>configuration
>variable.
>Relying on extensions or configuration flags to support core language
>features is very bad. We don't have flags that can turn IF support off
>for
>example, why we would have that for annotations?
I think you misunderstood: I didn't mean that users would need to turn that feature off, I
meant that that feature would be removed, and docblocks would always be saved.
>I can bring more cons if you want... like how/when to parse "use" calls
>in
>a docblock
In exactly the same place you'd parse them outside a docblock.
I really don't understand all these arguments about the parsing being harder. The only
difference is that you're parsing /** @Foo */ instead of <<Foo>> or whatever other
syntax anyone comes up with.
Really the only difference is that a docblock means sharing with other metadata (directives for
generating documentation). Which has the advantage of being polyfillable from older versions of PHP,
but the disadvantage of not being as clearly separated as a new type of syntax. Oh, and the
perception, right or wrong, that docblocks are "just comments", rather than metadata
containers, which Drupal's experience may demonstrate is more important than a purely rational
analysis would suggest.
All the other details about how this or that tool will adapt, how whitespace and multiline values
should be handled, etc, are going to need just as much thought whatever the syntax looks like.
Regards,
--
Rowan Collins
[IMSoP]