Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:49360 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 73146 invoked from network); 11 Aug 2010 18:30:38 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 11 Aug 2010 18:30:38 -0000 Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 207.97.245.113 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 207.97.245.113 smtp113.iad.emailsrvr.com Linux 2.4/2.6 Received: from [207.97.245.113] ([207.97.245.113:55489] helo=smtp113.iad.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 2A/EC-01618-D4CE26C4 for ; Wed, 11 Aug 2010 14:30:37 -0400 Received: from relay31.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay31.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id E868B1B4343 for ; Wed, 11 Aug 2010 14:30:34 -0400 (EDT) Received: by relay31.relay.iad.mlsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id BC5F61B4228 for ; Wed, 11 Aug 2010 14:30:34 -0400 (EDT) Message-ID: <4C62EC4A.9020106@sugarcrm.com> Date: Wed, 11 Aug 2010 11:30:34 -0700 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: PHP Internals Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: back to 5.4 alpha From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! I think by now, whatever you think on strict typing/typehints, it is clear to everybody that there's no consensus about this feature, and with Rasmus, Zeev & Andi, along with many others, being against it, as of now it can not be a part of an official PHP release. On the other hand, we have tons of cool features in trunk which aren't controversial and that we do want people to try out. So I'd propose doing the following: 1. Moving parameter typing to a feature branch (by branching current trunk and then rolling back the typing part in the trunk). 2. Starting 5.4 alpha process after that basing on trunk. Any objections to this? People that like the typing can still have them in the branch (and they can keep the branch as current as they want) and if we ever See The Light (TM) and want typed scalar parameters back, they're only a merge away. What do you think? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227