Nelson Menezes wrote: > On 6/16/05, Johannes Schlueter <[EMAIL PROTECTED]> 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
