On 05/05/2016 02:07 AM, Dmitry Stogov wrote:
Maybe that's what we want to have here - freedom for everybody to invent
their own languages - but I fear the danger of fragmentation here and
also people implementing tons of slightly different incompatible parsers
for ASTs that are generated. We'd have Drupal attributes and Symphony
attributes and Doctrine attributes and Zend attributes and so on, and
each of them would have different semantics. Not sure this would be
good. But maybe it avoids arguing about the syntax now.
Today, we have the same with doc-comments.
Attributes eliminate the need for separate parser and perform syntax
validation at compile time.
They also provide flexible syntax to support all existing annotation
systems, but they can't solve semantic problems, because they are just
meta-data.
This, I think, is the key point of disagreement.
The proposal does not, actually, provide enough functionality to be
useful. It's a first step, but it doesn't go far enough to actually
address the problem space. Because while it may provide rudimentary
syntax validation (basically, is it a legal PHP string) it doesn't
provide any semantic validation (it is a meaningful PHP string if
interpreted the right way), because it doesn't define "right way".
As Rowan noted, there are lots of technically-legal PHP strings that an
AST would be totally fine with that are still completely different and
incompatible as far as actually using them. To enhance his examples a bit:
<<Push($foo >> Translator)>>
<<Pipe($foo|lower|escape)>>
<<Query($foo ?? '//item[id=42]')>>
I could easily see, for instance, Doctrine annotations building the
first, PHPUnit the second, and Zend the 3rd. Those would all be
legal-ish, but semantically very different. And there's also then no
guarantee that $foo >> Translator actually means a bit-shift (I don't
even know what a bitshift in that case would mean), it could mean
anything that Doctrine decided to mutate it into. Does the second
example actually mean to pipe values, or could it also be parsed into
something else? Are lower and escape function names, or magic values
that my add-on parser knows?
At that point, the only value-add over the status quo (hack the
docblock) is a common lexer. But since the semantics are not guaranteed
on top of that, it's really not that useful.
I'm not fully convinced that all the way to Doctrine classes is the
right alternative. It may be, it may not be, I'm not sure yet. But as
someone who would be using this system in user-space, I am very
convinced that the current proposal simply doesn't go far enough to be
useful to me.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
