Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:52306 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 39962 invoked from network); 11 May 2011 16:59:27 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 11 May 2011 16:59:27 -0000 Authentication-Results: pb1.pair.com header.from=rasmus@lerdorf.com; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=rasmus@lerdorf.com; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain lerdorf.com from 209.85.160.42 cause and error) X-PHP-List-Original-Sender: rasmus@lerdorf.com X-Host-Fingerprint: 209.85.160.42 mail-pw0-f42.google.com Received: from [209.85.160.42] ([209.85.160.42:48904] helo=mail-pw0-f42.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id A4/80-36343-C60CACD4 for ; Wed, 11 May 2011 12:59:25 -0400 Received: by pwj3 with SMTP id 3so379815pwj.29 for ; Wed, 11 May 2011 09:59:21 -0700 (PDT) Received: by 10.142.211.18 with SMTP id j18mr5407438wfg.132.1305133161245; Wed, 11 May 2011 09:59:21 -0700 (PDT) Received: from [192.168.200.140] ([76.126.236.132]) by mx.google.com with ESMTPS id w11sm370682wfh.6.2011.05.11.09.59.19 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 May 2011 09:59:20 -0700 (PDT) Message-ID: <4DCAC067.5030801@lerdorf.com> Date: Wed, 11 May 2011 09:59:19 -0700 User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: "guilhermeblanco@gmail.com" CC: PHP internals References: <4DC729EE.9090600@sugarcrm.com> <4DC75FFF.40008@lerdorf.com> <4DC7A7F0.4000504@sugarcrm.com> <4DC819D0.5010008@lerdorf.com> <4DC81ED6.1050902@sugarcrm.com> <8757232E56758B42B2EE4F9D2CA019C9013F9F59@US-EX2.zend.net> <4DCA2192.4080201@lsces.co.uk> <4DCA5744.1030907@lerdorf.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] annotations again From: rasmus@lerdorf.com (Rasmus Lerdorf) On 05/11/2011 09:21 AM, guilhermeblanco@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