Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:20328 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 69420 invoked by uid 1010); 25 Nov 2005 04:30:30 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 69405 invoked from network); 25 Nov 2005 04:30:30 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 25 Nov 2005 04:30:30 -0000 Received: from ([127.0.0.1:25418]) by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with ECSTREAM id 17/E1-11378-66396834 for ; Thu, 24 Nov 2005 23:30:30 -0500 X-Host-Fingerprint: 144.134.252.58 dvpp-p-144-134-252-58.prem.tmns.net.au Received: from ([144.134.252.58:24493] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP id 21/D1-11378-F1096834 for ; Thu, 24 Nov 2005 23:16:31 -0500 Message-ID: <21.D1.11378.F1096834@pb1.pair.com> To: internals@lists.php.net Date: Fri, 25 Nov 2005 15:15:00 +1100 User-Agent: Thunderbird 1.4 (Windows/20050908) MIME-Version: 1.0 References: <3F.25.11378.CEA42834@pb1.pair.com> <018d01c5eeec$23949600$5c8be5a9@ohr.berkeley.edu> <497935ba0511211511l5867410dk577deb60b998a069@mail.gmail.com> <497935ba0511211512k4c8e1cb4r89cf1ffcd4ab7829@mail.gmail.com> <438254E6.2050903@prohost.org> <497935ba0511211609n675a3c3yf03cb5e5e97bb5bf@mail.gmail.com> <4382BDA2.4050806@php.net> <497935ba0511220024l492112f7nfe2c05d27d65e1a5@mail.gmail.com> <497935ba0511220024j4a189b94r667945241f1811f8@mail.gmail.com> <497935ba0511220159y14dc36cra39e28d7d617a03b@mail.gmail.com> <13067.64.241.37.140.1132675931.squirrel@www.quo.org> In-Reply-To: <13067.64.241.37.140.1132675931.squirrel@www.quo.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Posted-By: 144.134.252.58 Subject: Re: [PHP-DEV] Re: Syntax in PHP 6 From: spam_me@mjec.net (Michael Cordover) status@quo.org wrote: > Perhaps this has already been proposed and I missed it as I'm new to the > list, but why not set a release in the future, say PHP8, in which there > will be no holds barred about breaking bc? Everyone would know that this > upcomming release would be the one that resolves all inconsistencies with > lots of time to debate them and get ready for the upgrade, and meanwhile > people who complain could be told to wait for release x and told where > they can give their opinion about styles etc. Ok, so I know this is already close to a flamewar and I don't mean to add to that, but how difficult would it be to select a naming scheme, shove all the functions into and alias the non-conforming names to those functions. New code would be consistent, old code would work. And then at PHP 8 or so the old versions could be totally scrapped. I'm probably missing some basic impediment to doing this and I'd appreciate it being pointed out to me - with or without a smiley ;). -mjec -- http://mine.mjec.net/