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 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. 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". > > johannes > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Nelson Menezes [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
