Ok, so I'll explain why it's not "the same way" as you imagine.
I've heard this many times already so I'll save you keystrokes.
- "Sure, we can do that on docblocks"
- "Based on that, it doesn't need to be part of core and can safely be
implemented as a PECL extension"
IMHO, internals need to stop considering that PECL is a space for beta
testing features, 95% of userland doesn't even know what PECL is.
Now back to business. At parsing level, PHP has its own parser which we
could take advantage of, and though PECL extension would have to create
one. Clearly not the same way.
The closest stage we can start with this at parsed and resolved AST level
(or enter on the dark side of PHP rewriting stuff like xdebug does).
At that stage, we'd already have resolved classnames, but not for those
annotations in docblock, which is a simple block of text so far. We'd also
have to introspect the AST before it pushes to zend_compile, where use
states are vanished and all classes are already string-resolved into their
corresponding FQCN. And we still have to resolve the class names in the
docblocks using USE statements at AST level, we don't even have the
zend_class_entry instances done at that point, because they're only built
later. Not the same way, again.
Considering I've resolved these problems, it starts wit managing these data
structures. At AST level, we don't have the zend_class_entries, but I'd
already be forced to create instances of specific annotation instances. And
also I need to manage keeping my own data structures, cache them through
opcode and also implement/override Reflection data structures to enable
access to specific annotated elements. Still not the same thing.
Now let's enter on logistics of parsing the docblock text. It's multi-lined
and parsing strings like the one I sent you as an example that you ignored
to answer me back replying "it's just the same way" of parsing now need to
be away of line and column location and carefully remove pieces of text
(remember the " * " I commented?), leading to unexpected behavior and
potentially removing user's text, while re2c would already have done for
us. Again, not the same way.
I can't even imagine how can you bindly say the implementation would be the
same or act the same way as a docblock implementation. It's incredibly
complex, error prone and unreliable to be ensured present (well, it'd be an
optional extension, right?) for such an intrinsic to the language data
structure. We didn't make namespaces a PECL extension, we didn't make
traits part of docblocks. I'd argue traits is not widely used too and the
introduced complexity to core was very big. It could easily be solved by
"using traits" through docblocks and general classes too. Why your argument
is applicable to one thing and not the other?
If anyone is really willing to actually discuss true annotations
implementation and behavior in core, I'm here to help. Until then, I'll
keep watching the list.
Ah, and please stop saying "it should be in docblock". This argument is
just bull... to suppress the actual people interested to see this natively
available and just exposes your lack of interest into language improvement.
On Wed, Nov 25, 2015 at 5:03 PM, Rowan Collins wrote:
On 25 November 2015 19:02:37 GMT, "email@example.com
If you're in a shared hosting, you can't "simply" remove the
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
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 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.
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Toronto - ON/Canada