Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:64658 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 71218 invoked from network); 8 Jan 2013 08:55:18 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 8 Jan 2013 08:55:18 -0000 Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.143 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 67.192.241.143 smtp143.dfw.emailsrvr.com Linux 2.6 Received: from [67.192.241.143] ([67.192.241.143:50825] helo=smtp143.dfw.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id EE/A3-37176-5FEDBE05 for ; Tue, 08 Jan 2013 03:55:18 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp24.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id EB474180D00; Tue, 8 Jan 2013 03:55:14 -0500 (EST) X-Virus-Scanned: OK Received: by smtp24.relay.dfw1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 6B948180259; Tue, 8 Jan 2013 03:55:14 -0500 (EST) Message-ID: <50EBDEEE.8070605@sugarcrm.com> Date: Tue, 08 Jan 2013 00:55:10 -0800 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Rasmus Schultz CC: "internals@lists.php.net" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [RFC] Reflection annotations reader From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > First of all, there are already plenty of established userland > implementations - so there is really no need for this. On the contrary, plenty of implementations means there's a need in this functionality, and it might be a good idea to have one standard implementation if it can cover like 80% of use cases. > > Whatever you decide on in terms of syntax, most likely won't satisfy every > the needs of every userland annotation library, so at least some of them > most likely won't use it. You'd be creating more work for the maintainers > of these frameworks, and they don't standard to gain anything from that > work. Since when "it does not satisfy all needs of all users, and some of them may end up not using it" is an argument for not including functionality? And how it's more work for maintainers if they just won't use it? > On the other hand, I would be interested in having support for actual > annotation syntax (not docblocks) added to PHP. Real annotation syntax Can we please not hijack the topic? We discussed annotations many times already, if you have better proposal than current RFCs please create your own RFC (or ask one of the current RFC authors for collaboration) and start a new topic -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227