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. Regards, On Wed, Nov 25, 2015 at 5:03 PM, Rowan Collins <rowan.coll...@gmail.com> wrote: > On 25 November 2015 19:02:37 GMT, "guilhermebla...@gmail.com" < > guilhermebla...@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] > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Guilherme Blanco MSN: guilhermebla...@hotmail.com GTalk: guilhermeblanco Toronto - ON/Canada
