Hey David & Lucas,
I brought this up a year ago on the list here:
http://marc.info/?t=114728193700003&r=1&w=2
Essentially, the trend will continue to be that as keyword requiring
features are added, the global naming space will continue to become
smaller and less safe for older applications written for older versions
of php.
Until it becomes a goal of php-internals to add contextual awareness and
sensitivity to the compiler's tokenizer, this will always be a problem.
Here is a more amusing list of method names that will also not work:
http://marc.info/?l=php-dev&m=114736739115429&w=2
And the general opinion summed up by Wez ;)
http://marc.info/?l=php-dev&m=114764099400409&w=2
-ralph
David Coallier wrote:
On 8/16/07, Marcus Boerger <[EMAIL PROTECTED]> wrote:
Hello Lukas,
this is a no issue. Prefix your code and be done!
That means prefixing your methods as well ?
The problem is when one calls something like a method "import()"
You prefix your functions ? I think this is silly. Prefix the class to
make it namespace** like, but not the methods...
PEAR_ClassName {
public static function __PEAR_construct() { }
public static function PEAR_import() { }
public static function PEAR_export() { }
}
Which ends in
PEAR_ClassName::PEAR_Import();
Whereas:
PEAR_ClassName::import(); would usually be ok to do.
Prefixing the methods imho is the no go in this case.
marcus
Wednesday, August 15, 2007, 3:37:20 PM, you wrote:
Hi,
Someone in the Doctrine channel just brought up the issue of having to
look forward to ensure mid term compatibility when choosing names for
identifiers. I guess with namespaces and other things will add new
reserved words. I think we should have a prominent place on php.net with
early warning for reserved words that will be in future php releases.
regards,
Lukas
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
