Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » reserved word alert »

reserved word alert

php.internals

Lukas Kahwe Smith

19 years ago
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

Alain Williams

19 years ago
On Wed, Aug 15, 2007 at 03:37:20PM +0200, Lukas Kahwe Smith 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.
No future reserved word will contain a capital letter (unless it is entirely caps - constant). So: nice simple rule - include a capital letter in all your variable/function/... names.
-- Alain Williams Linux Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php Chairman of UKUUG: http://www.ukuug.org/ #include <std_disclaimer.h>

Hannes Magnusson

19 years ago
On 8/15/07, Alain Williams <addw@phcomp.co.uk> wrote:
> On Wed, Aug 15, 2007 at 03:37:20PM +0200, Lukas Kahwe Smith 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. > > No future reserved word will contain a capital letter (unless it is entirely caps - constant).
Where did you get that idea?
> So: nice simple rule - include a capital letter in all your variable/function/...
functions, classnames and methods.... are case-insensitive. Only variables are case-sensitive. -Hannes

Tomas Kuliavas

19 years ago
>> 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. > > No future reserved word will contain a capital letter (unless it is > entirely caps - constant). > So: nice simple rule - include a capital letter in all your > variable/function/... names.
And make sure that it is not Latin capital letter i. PHP bug 18556 Some parts of interpreter are still locale aware in case insensitive comparison. Test by mike dot ditum still works in php5.2-200708151230 and 6.0-200708151230.
-- Tomas

Hannes Magnusson

19 years ago
On 8/15/07, Lukas Kahwe Smith <mls@pooteeweet.org> 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.
Meaning somewhere like http://php.net/reserved ? :) -Hannes

Lukas Kahwe Smith

19 years ago
Hannes Magnusson wrote:
> On 8/15/07, Lukas Kahwe Smith <mls@pooteeweet.org> 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. > > Meaning somewhere like http://php.net/reserved ? :)
I mean we should frequently mention it. Hmm maybe what we need is a forward compatibility newsletter instead. Just something that summarizes the last 4 weeks worth of BC breaks :) Guess this can/should then however be semi independent of php.net. I will ponder if I have the motivation to do this. People helping would be an encouragement :) regards, Lukas

Marcus Börger

19 years ago
Hello Lukas, this is a no issue. Prefix your code and be done! 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

Nicolas Bérard Nault

19 years ago
In that specific case, a method called import() was in cause (of course, conflicting with the namespace/package/whatever package). Do you propose prefixing all method names ? On 8/16/07, Marcus Boerger <helly@php.net> wrote:
> > Hello Lukas, > > this is a no issue. Prefix your code and be done! > > 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 > >
-- Nicolas Bérard-Nault (nicobn@gmail.com) Étudiant D.E.C. Sciences, Lettres & Arts Cégep de Sherbrooke Homepage: http://nicobn.googlepages.com

Marcus Börger

19 years ago
Hello Nicolas, yes. All my global functions and my classes are prefixed. marcus Thursday, August 16, 2007, 10:37:30 PM, you wrote:
> In that specific case, a method called import() was in cause (of course, > conflicting with the namespace/package/whatever package). Do you propose > prefixing all method names ?
> On 8/16/07, Marcus Boerger <helly@php.net> wrote: >> >> Hello Lukas, >> >> this is a no issue. Prefix your code and be done! >> >> 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 >> >>
Best regards, Marcus

Nicolas Bérard Nault

19 years ago
I wasn't talking about global functions and classes, I was talking about class methods. David pretty much sums this up in his email. On 8/16/07, Marcus Boerger <helly@php.net> wrote:
> > Hello Nicolas, > > yes. All my global functions and my classes are prefixed. > > marcus > > Thursday, August 16, 2007, 10:37:30 PM, you wrote: > > > In that specific case, a method called import() was in cause (of course, > > conflicting with the namespace/package/whatever package). Do you propose > > prefixing all method names ? > > > On 8/16/07, Marcus Boerger <helly@php.net> wrote: > >> > >> Hello Lukas, > >> > >> this is a no issue. Prefix your code and be done! > >> > >> 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.netwith > >> > 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 > >> > >> > > > > > > Best regards, > Marcus > >
-- Nicolas Bérard-Nault (nicobn@gmail.com) Étudiant D.E.C. Sciences, Lettres & Arts Cégep de Sherbrooke Homepage: http://nicobn.googlepages.com

Pierre Joye

19 years ago
On 8/16/07, Marcus Boerger <helly@php.net> wrote:
> Hello Nicolas, > > yes. All my global functions and my classes are prefixed.
Prefix the methods are not a solution. The only cases where it is acceptable are the magic methods (when we introduce new ones) like __get/set. But that happens rarely. --Pierre

David Coallier

19 years ago
On 8/16/07, Marcus Boerger <helly@php.net> 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 > >
-- David Coallier, Founder & Software Architect, Agora Production (http://agoraproduction.com) 51.42.06.70.18

Ralph Schindler

19 years ago
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:

Greg Beaver

19 years ago
Ralph Schindler wrote:
> 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
Hi, Doing this with flex is non-trivial. It's a lot easier with a re2c-based lexer, but porting the flex scanner to re2c is the definition of "oh-my-god-almighty" complex and until someone just does it, it ain't gonna happen. The other hackish alternative is to add rules to the parser with reserved words (T_FUNCTION T_IMPORT as well as T_FUNCTION T_STRING, etc. etc.), but this slows down the parser and adds unnecessary duplication. Greg

Marcus Börger

19 years ago
Hello Gregory, the good news on this fron is that re2c meanwhile has a new beta version with flex like conditoin support. Also when changing from flex to re2c we should switch from bison to lemon. All in all a damn huge amount of work. But the result would be much cleaner, faster, more flexible, fully reentrant, reuseable outside of the engine and cabable of unicode.... Yet you mentioned the big issue, someone would need to do this. Though the biggest entry on the to do would be discussing it ... hopefully not needting to rename something marcus Friday, August 17, 2007, 7:35:43 PM, you wrote:
> Ralph Schindler wrote: >> 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
> Hi,
> Doing this with flex is non-trivial. It's a lot easier with a > re2c-based lexer, but porting the flex scanner to re2c is the definition > of "oh-my-god-almighty" complex and until someone just does it, it ain't > gonna happen.
> The other hackish alternative is to add rules to the parser with > reserved words (T_FUNCTION T_IMPORT as well as T_FUNCTION T_STRING, etc. > etc.), but this slows down the parser and adds unnecessary duplication.
> Greg
Best regards, Marcus

Richard Lynch

19 years ago
I think we should rename flex to something else because you just confused me with that new Adobe not-quite-flash flex thingie... :-) :-) ;-) Just Kidding!!! (Not about the confusing me part, as we all know that's trivial...) On Mon, August 20, 2007 5:04 am, Marcus Boerger wrote:
> Hello Gregory, > > the good news on this fron is that re2c meanwhile has a new beta > version > with flex like conditoin support. Also when changing from flex to re2c > we > should switch from bison to lemon. All in all a damn huge amount of > work. > But the result would be much cleaner, faster, more flexible, fully > reentrant, reuseable outside of the engine and cabable of unicode.... > Yet you mentioned the big issue, someone would need to do this. Though > the > biggest entry on the to do would be discussing it ... hopefully not > needting > to rename something > > marcus > > Friday, August 17, 2007, 7:35:43 PM, you wrote: > >> Ralph Schindler wrote: >>> 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 > >> Hi, > >> Doing this with flex is non-trivial. It's a lot easier with a >> re2c-based lexer, but porting the flex scanner to re2c is the >> definition >> of "oh-my-god-almighty" complex and until someone just does it, it >> ain't >> gonna happen. > >> The other hackish alternative is to add rules to the parser with >> reserved words (T_FUNCTION T_IMPORT as well as T_FUNCTION T_STRING, >> etc. >> etc.), but this slows down the parser and adds unnecessary >> duplication. > >> Greg > > > > > Best regards, > Marcus > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
-- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So?