On 05/11/2011 09:21 AM, guilhermebla...@gmail.com wrote:
The only point that I see here is that none of them heavily rely on
this feature.
Doctrine/Symfony relies a lot on it, and requires special treatment
that key => value support is not enough.
Please check out these pages for reference:
Doctrine 2 Association mapping:
http://www.doctrine-project.org/docs/orm/2.0/en/reference/association-mapping.html#mapping-defaults
Symfony 2 Validation mapping (click on Annotations tab):
http://symfony.com/doc/current/book/validation.html#constraint-configuration
That's the point that I'd like to illustrate.
PHP still lack of standardization in so many places. That's why I took
the most complete approach that could fit in every library I've looked
at.
All I just don't want is to implement a docblock solution that in next
major becomes a separate thing as happened to Java.
My first patch (and I dunno if you remember) was around 80% compatible
with JSR-250, which was carefully planned and discussed by Java folks.
Of course it was a different implementation, without extra burden and
with the inclusion of other powerful artifacts.
Now I'm going to release another RFC for Annotations within docblocks,
but I would really hope that you understand the needs of complex
support instead of a key/value one.
My main concern is the trickle-down effect a major low-level engine
addition causes. Your patch is just the tip of the iceberg which will
cause dozens of people weeks of work to account for the new code all
across the PHP ecosystem. The most complicated being the opcode cache
support which really only can be written by a handful of people due to
the complexity involved. Combine that with the fact that other projects
who currently use annotations, perhaps not to the level of Doctrine, but
still, state that they would have a hard time switching to this new
approach it becomes really hard to commit all these people and all this
time to this.
We are severely resource-constrained when it comes to people who can
write solid low-level C code and we have to be very careful what we ask
our volunteers to spend their time on. A volunteer developer who isn't
excited about a feature is going to drag her feet and it will sit
solidly at the bottom of the priority list for months, if not years. If
a key piece of the eco-system isn't updated because of this one
addition, it means that potential PHP 5.4 users may have to wait 6, 12,
18 months before they can migrate to the new version.
Therefore, low-level engine changes, syntax additions, or entirely new
grammars as is the case here, face an uphill battle. If there is a way
to currently solve the problem without major changes, even if it is an
80% solution that will weigh heavily against accepting the new code.
Without broad support and enthusiasm, especially from the people who
have historically been the ones that write the code and track down and
fix the bugs, low-level features like this are doomed, no matter how
well-intentioned they are.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
