On 05/06/2016 05:06 AM, Jesse Schalken wrote:
If you're going to say "do what you want" with regards to annotations, then
just let them be a text string. Parsing the annotation as PHP but not
evaluating it as PHP seems a very strange and arbitrary half-way point. If
the thing consuming the AST is expected to eval() it, then why didn't PHP
do that already? If the thing consuming the AST is expected not to eval()
it, then it must effectively implement it's own language sharing PHP's
syntax but not PHP's semantics. Since it can't possibly attach meaning to
all of PHP's syntax, PHP will enforce that the string is valid PHP even
though the annotation language will be a very small subset. Not only does
that buy you very little in terms of validity checking, but it constrains
the annotation language to be a subset of PHP's syntax even when such a
constraint may be entirely inappropriate.
A true "do what you want" approach, if that is the right approach, would be
for the annotation body to be a free text string.
You talk about a subset of the proposed RFC.
It proposes an additional question about AST usage.
Thanks. Dmitry.
On Fri, May 6, 2016 at 8:36 AM, Dan Ackroyd <dan...@basereality.com> wrote:
On 5 May 2016 at 15:24, Larry Garfield <la...@garfieldtech.com> wrote:
because it doesn't define "right way".
Good.
I could easily see, for instance, Doctrine annotations building the
first, PHPUnit the second, and Zend the 3rd.
Good!
It's not the job of PHP core to tell people how to use annotations.
People can use them however they want.
If it turns out that there is a single 'right' way of using them,
everyone will gravitate to that way anyway.
If it turns out there are different 'right' ways of using them for
different use cases, people will be able to pick and choose the
use-case that is most appropriate.
And most importantly, if what people think is the 'right' way to use
them evolves over time, that can be accomplished completely in
user-land, without needing to update the internal implementation of
annotations.
cheers
Dan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
