Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:16772 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 63318 invoked by uid 1010); 17 Jun 2005 06:32:39 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 63301 invoked from network); 17 Jun 2005 06:32:39 -0000 Received: from unknown (HELO pb1.pair.com) (127.0.0.1) by localhost with SMTP; 17 Jun 2005 06:32:39 -0000 X-Host-Fingerprint: 84.148.148.249 p549494F9.dip0.t-ipconnect.de Received: from ([84.148.148.249:19391] helo=localhost.localdomain) by pb1.pair.com (ecelerity 1.2 r(5656M)) with SMTP id 50/53-20931-5B762B24 for ; Fri, 17 Jun 2005 02:03:34 -0400 Message-ID: <50.53.20931.5B762B24@pb1.pair.com> To: internals@lists.php.net Date: Fri, 17 Jun 2005 08:10:19 +0200 User-Agent: Mozilla Thunderbird 1.0+ (Windows/20050614) MIME-Version: 1.0 References: <42B13E9A.7080706@php-tools.net> <95.E7.20931.05441B24@pb1.pair.com> <200506161126.44054.johannes@php.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Posted-By: 84.148.148.249 Subject: Re: [PHP-DEV] forward compatibility "public" in 4.4 From: lists@sebastianmendel.de (Sebastian Mendel) Nelson Menezes wrote: > On 6/16/05, Johannes Schlueter wrote: >> On Thursday 16 June 2005 11:27, Sebastian Mendel wrote: >>>> I guess, this will more likely produce an error message like this: >>>> >>>> Parse error: syntax error, unexpected T_PUBLIC, expecting T_STRING in >>>> public.php on line 2 >> >> right >> >>>> So I'm strongly against this change. If you want to run PHP4 code in >>>> PHP5, disable E_STRICT. >> >> +1 >> >>> id dont know, but isnt there a difference between where the keywords are >>> placed? >> >> No, it's a parser keyword and a keyword can't be used as a function name. >> >>> and if it is so, then this would also be a candidate for >>> >>> "NOTICE: 'public' is a keyword in PHP 5" in php 4.4 >> >> No. No "errors" for "forward compatibility". > > I completely agree. This (or any other "public-in-4.4" solution) would > only create an extra branch to maintain for both developers and users; > no one can expect all of the PHP 4.x base to go 4.4, and code with > "public" that "supports php 4 and 5" would actually break in 4.<4 and > still would be: > > - unable to use PHP 5 > - subject to the other PHP 4/5 issues of course, id dont want any changes that break compatibility! > Besides, the point of E_STRICT seems to be to _enforce_ best practices > -- and if you care about this matter, considering all members as > "public" is probably defying the concept anyway. but defining all as public doesnt produces any NOTICEs, neither now nor with the feature we are talking about. -- Sebastian Mendel www.sebastianmendel.de www.sf.net/projects/phpdatetime | www.sf.net/projects/phptimesheet