Dan Ackroyd wrote on 24/04/2016 21:45:
The point I was trying to make is that it explicitly says that "this is a userland attribute", rather than using the generic <<...>> syntax, which we might want to use for non-userland attributes at some point.
I think framing the problem as "engine vs userland" is misleading; what you are actually saying is "how do we avoid name collisions?"
There's currently no difference in syntax between userland and engine functions and classes, and *that is a good thing*, because it means you can transparently apply polyfills, create C / Zephir extensions to replace performance-sensitive functions, etc. The same could be done for annotations - if it's possible to create a userland DBC library, then why shouldn't it be able to polyfill the same syntax as an engine one?
As mentioned elsewhere, in an OO implementation of annotations, the existing namespace hierarchy could be used (which includes the \php\ reservation, which we've never taken advantage of). If it's not, we are left with naming conventions.
I would suggest that even if we don't have objects representing the annotations, "\" should be allowed, and encouraged, in their names. Thus, *by convention*, attributes would be prefixed with at least a vendor name ("<<Doctrine\Foo>>", etc).
PHP could reserve "__" and "php\" for future internal use, but also semi-reserve the global namespace, as described here: http://php.net/manual/en/userlandnaming.rules.php
> PHP owns the top-level namespace but tries to find decent descriptive names and avoid any obvious clashes.
If somebody creates a userland library that uses <<DBC\Require(...)>>, it's up to them to deal with the consequences if PHP later implements an incompatible version, just as it would be if they wrote a function called dbc_require(), or DBC::require().
Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
