# reserved word alert - Thread: https://externals.io/message/31576 - Original archive: https://news-web.php.net/php.internals/31576 - Started by Lukas Kahwe Smith on 2007-08-15T13:37:20+00:00 - Messages: 16 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #31576 — Lukas Kahwe Smith — 2007-08-15T13:37:20+00:00 URL: https://externals.io/message/31576#31576 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 --- ## #31578 — Alain Williams — 2007-08-15T13:43:22+00:00 URL: https://externals.io/message/31576#31578 · In reply to: #31576 > 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 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 --- ## #31581 — Hannes Magnusson — 2007-08-15T14:27:41+00:00 URL: https://externals.io/message/31576#31581 · In reply to: #31578 > > > […] > > 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 --- ## #31582 — Tomas Kuliavas — 2007-08-15T14:45:42+00:00 URL: https://externals.io/message/31576#31582 · In reply to: #31578 > > […] > > 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 --- ## #31595 — Lukas Kahwe Smith — 2007-08-15T19:45:35+00:00 URL: https://externals.io/message/31576#31595 · In reply to: #31580 Hannes Magnusson wrote: > > > […] > > 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 --- ## #31649 — Marcus Boerger — 2007-08-16T20:23:40+00:00 URL: https://externals.io/message/31576#31649 · In reply to: #31576 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 --- ## #31650 — nicobn@gmail.com — 2007-08-16T20:37:30+00:00 URL: https://externals.io/message/31576#31650 · In reply to: #31649 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 ? > > Hello Lukas, > > this is a no issue. Prefix your code and be done! > > marcus > > Wednesday, August 15, 2007, 3:37:20 PM, you wrote: > > > […] > > > […] > > > […] > > > > > 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 --- ## #31652 — Marcus Boerger — 2007-08-16T20:43:22+00:00 URL: https://externals.io/message/31576#31652 · In reply to: #31650 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 ? > > > […] Best regards, Marcus --- ## #31653 — David Coallier — 2007-08-16T20:46:06+00:00 URL: https://externals.io/message/31576#31653 · In reply to: #31649 > 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: > > > […] > > > […] > > > […] > > > > > Best regards, > Marcus > > -- > > > > -- David Coallier, Founder & Software Architect, Agora Production (http://agoraproduction.com) 51.42.06.70.18 --- ## #31665 — nicobn@gmail.com — 2007-08-17T03:40:10+00:00 URL: https://externals.io/message/31576#31665 · In reply to: #31652 I wasn't talking about global functions and classes, I was talking about class methods. David pretty much sums this up in his email. > > Hello Nicolas, > > yes. All my global functions and my classes are prefixed. > > marcus > > Thursday, August 16, 2007, 10:37:30 PM, you wrote: > > > […] > > > […] > to > > […] > > > > > > 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 --- ## #31667 — Pierre — 2007-08-17T05:36:34+00:00 URL: https://externals.io/message/31576#31667 · In reply to: #31652 > 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 --- ## #31698 — Ralph Schindler — 2007-08-17T16:50:03+00:00 URL: https://externals.io/message/31576#31698 · In reply to: #31653 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: > > > […] > > 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. > > […] --- ## #31706 — Gregory Beaver — 2007-08-17T17:35:43+00:00 URL: https://externals.io/message/31576#31706 · In reply to: #31698 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 --- ## #31729 — Marcus Boerger — 2007-08-20T10:04:44+00:00 URL: https://externals.io/message/31576#31729 · In reply to: #31706 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: > > […] > 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 --- ## #31914 — Richard Lynch — 2007-08-26T04:55:10+00:00 URL: https://externals.io/message/31576#31914 · In reply to: #31729 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...) > 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: > > > […] > > > […] > > > […] > > > […] > > > […] > > > > > Best regards, > Marcus > > -- > > > > -- 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?