Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:48036 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 24726 invoked from network); 21 Apr 2010 13:24:38 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 21 Apr 2010 13:24:38 -0000 X-Host-Fingerprint: 64.8.134.189 unknown Received: from [64.8.134.189] ([64.8.134.189:2559] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id DD/1D-63467-59CFECB4 for ; Wed, 21 Apr 2010 09:24:38 -0400 To: internals@lists.php.net,Stanislav Malyshev Message-ID: <4BCEFC93.7010508@gmail.com> Date: Wed, 21 Apr 2010 08:24:35 -0500 User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 CC: Adi Nita References: <4BCE44B8.6060600@zend.com> In-Reply-To: <4BCE44B8.6060600@zend.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Posted-By: 64.8.134.189 Subject: Re: [PHP-DEV] A critique of PHP 6 From: rpanning@gmail.com (Ryan Panning) Stanislav Malyshev wrote: >> 1. SYSTEM NAMESPACES. > Come on. Is it really that hard to write strlen? Or array_merge? Would > it be better if they were len (of what?) and merge (what?)? I don't > think so. No, it is not hard to write strlen but I would also like to see these functions organized better. I've felt that PHP has been a mess since I learned it way back when, the naming inconsistencies are everywhere. >> 2. TYPE HINTING. > This topic was discussed to death on the list, please read the archives. > If after that you still do not understand what it is about, or have some > comments, please ask then. Sure, it has been discussed over and over but the fact that it keeps coming up here should show you that PHP developers want this feature. >> 4. PARAMETER ORDER. > Two letters: BC. > Changing variable order in an existing function is a big fat BC break. > And if we put such a bomb into a new version, what would be the > incentive for people to use it? So that apps would have to be shipped in > 2 versions, for the old php and the new php? Is this something that could be fixed if it's moved to a namespace? The new "alias" can have the "correct" order but original function can have the old order. >> These were the major issues that came to my mind until now. > Please remember - what you call "ancient code" other people call > "application on which my paycheck depends". So I think we should be > super-extra-careful when messing with it. That doesn't mean we would > never do any BC-breaking change ever - that does mean there always has > to be a very good reason for it. And I personally don't see > "consistency" being good enough reason. Don't get me wrong - it's good, > it's just not good enough to be valued over working applications. I agree here but again, it could probably be worked around with some thought. These are a few items that I'd like to see worked on, as a PHP developer anyway. At the same time, I'd like to thank the internal developers. Several other things that were on my list have been worked on, specifically Late Static Bindings. Thanks again, these are just my comments, not meant to offend anyone.